This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/JVMTI] GetMethodDeclaringClass


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?\

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]