This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [RFC/JVMTI] GetMethodDeclaringClass
- From: Andrew Haley <aph at redhat dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>
- Date: Tue, 17 Oct 2006 19:14:10 +0100
- Subject: Re: [RFC/JVMTI] GetMethodDeclaringClass
- References: <45351C48.5070205@redhat.com>
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.