Re: [RFC/JVMTI] GetMethodDeclaringClass

[Andrew Haley <aph@redhat.com>]

Andrew Haley writes:
 > Keith Seitz writes:
 >  > 
 >  > Okay, well, I hate to be indecisive, but I've spent a lot of time being 
 >  > really wishy-washy on this, so I'm leaving it up to the collective 
 >  > wisdom of the maintainers and other developers. :-)
 >  > 
 >  > JVMTI has a function called GetMethodDeclaringClass which is a real 
 >  > pain. Unlike JDWP and JNI, JVMTI does *not* pass class IDs and method 
 >  > IDs together. JVMTI simply passes around the jmethodID. As a result, we 
 >  > have the evil known as GetMethodDeclaringClass, which is going to be 
 >  > required for JDWP (and probably any other real-world JVMTI agent).
 >  > 
 >  > So somehow we must maintain a mapping of jmethodIDs to their 
 >  > corresponding classes. I've played around with this quite a bit 
 >  > recently, and I've come to two solutions for this problem, both with 
 >  > pros and cons. [I have hacked both these solutions together; rough 
 >  > patches on request.]
 >  > 
 >  > It is up to you, gentle reader, to pick one of these solutions or offer 
 >  > another up for review. [I should mention a small aside: both JDWP and 
 >  > JVMTI also have a function to get all the classes in the VM for which 
 >  > this could also be used.]
 >  > 
 >  > 1) the simple method
 >  > ClassLoaders already contain a list of all the classes they've loaded. 
 >  > So by adding some code to java.lang.ClassLoader, we can keep track of 
 >  > all the ClassLoaders in the system. We can then do several things to 
 >  > search through those loaded classes: loop through the classes (dog 
 >  > slow), sort the loaded classes and then search (I'm guessing not 
 >  > feasible for a large number of classes), etc.
 >  > 
 >  > 2) maintain yet another list of loaded classes
 >  > Yes, I hate to say it, but this is on the table. If it isn't bad enough 
 >  > that java.lang.ClassLoader and the stacktracing code maintain lists of 
 >  > loaded classes, I'm proposing adding one more, which builds on the 
 >  > stacktracing code's _Jv_{Pop,Push}Class. I've implemented this with a 
 >  > TreeSet and a custom Comparator. [It maintains a list of classes, not 
 >  > jmethodIDs!]
 >  > 
 >  > 3) ???
 >  > 
 >  > Any comments or other ideas?
 > 
 > What is a jmethodID?  How is it created?\

Ah, sorry.  I thought you meant something internal to JVMTI, but I
guess you mean libgcj's jmethodID.

AFAICS we just need to make sure that all methods for interpreted
classes are pushed with _Jv_PushClass.  Then to get your class,

 class = ncodeMap->get (jmethodID->ncode);

Andrew.