[RFC/JVMTI] GetMethodDeclaringClass

[Keith Seitz]

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