From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18600 invoked by alias); 17 Oct 2006 19:05:58 -0000 Received: (qmail 18591 invoked by uid 22791); 17 Oct 2006 19:05:56 -0000 X-Spam-Check-By: sourceware.org Received: from monty-python.gnu.org (HELO monty-python.gnu.org) (199.232.76.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Oct 2006 19:05:50 +0000 Received: from [66.187.237.31] (helo=mx2.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GZthc-0008KV-64 for java-patches@gcc.gnu.org; Tue, 17 Oct 2006 14:30:12 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9HIT3iD010794 for ; Tue, 17 Oct 2006 14:29:03 -0400 Received: from zebedee.littlepinkcloud.COM (vpn-14-51.rdu.redhat.com [10.11.14.51]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9HISxVp011224; Tue, 17 Oct 2006 14:29:00 -0400 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id k9HISvdO005357; Tue, 17 Oct 2006 19:28:58 +0100 Received: (from aph@localhost) by littlepinkcloud.COM (8.13.6/8.13.5/Submit) id k9HISvvP005354; Tue, 17 Oct 2006 19:28:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17717.8425.50456.767598@zebedee.pink> Date: Tue, 17 Oct 2006 19:05:00 -0000 From: Andrew Haley To: Keith Seitz , Java Patch List Subject: Re: [RFC/JVMTI] GetMethodDeclaringClass In-Reply-To: <17717.7538.291407.210562@zebedee.pink> References: <45351C48.5070205@redhat.com> <17717.7538.291407.210562@zebedee.pink> X-Mailer: VM 7.19 under Emacs 21.4.1 X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2006-q4/txt/msg00067.txt.bz2 Andrew Haley writes: > 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?\ Ah, sorry. I thought you meant something internal to JVMTI, but I guess you mean libgcj's jmethodID. AFAICS we just need to make sure that all methods for interpreted classes are pushed with _Jv_PushClass. Then to get your class, class = ncodeMap->get (jmethodID->ncode); Andrew.