From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25193 invoked by alias); 17 Oct 2006 18:09:33 -0000 Received: (qmail 25174 invoked by uid 22791); 17 Oct 2006 18:09:26 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Oct 2006 18:09:17 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9HI9ETi014504 for ; Tue, 17 Oct 2006 14:09:14 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9HI9EW9007813 for ; Tue, 17 Oct 2006 14:09:14 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.12.8) with ESMTP id k9HI9C1f018361 for ; Tue, 17 Oct 2006 14:09:13 -0400 Message-ID: <45351C48.5070205@redhat.com> Date: Tue, 17 Oct 2006 18:09:00 -0000 From: Keith Seitz User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Java Patch List Subject: [RFC/JVMTI] GetMethodDeclaringClass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00062.txt.bz2 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