This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
[RFC/JVMTI] GetMethodDeclaringClass
- From: Keith Seitz <keiths at redhat dot com>
- To: Java Patch List <java-patches at gcc dot gnu dot org>
- Date: Tue, 17 Oct 2006 11:09:12 -0700
- Subject: [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