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]

[RFC/JVMTI] GetMethodDeclaringClass


Hi,

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?

Keith


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