From kato-spec-return-169-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Wed May 13 12:49:02 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 48006 invoked from network); 13 May 2009 12:49:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 May 2009 12:49:02 -0000 Received: (qmail 5971 invoked by uid 500); 13 May 2009 12:49:02 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 5941 invoked by uid 500); 13 May 2009 12:49:02 -0000 Mailing-List: contact kato-spec-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-spec@incubator.apache.org Delivered-To: mailing list kato-spec@incubator.apache.org Received: (qmail 5931 invoked by uid 99); 13 May 2009 12:49:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 May 2009 12:49:02 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.126.177] (HELO moutng.kundenserver.de) (212.227.126.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 May 2009 12:48:52 +0000 Received: from [9.20.184.188] (blueice3n1.uk.ibm.com [195.212.29.83]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MKuxg-1M4Dss3RUH-0001Bx; Wed, 13 May 2009 14:48:30 +0200 Message-ID: <4A0AC1A2.8070307@stoo.me.uk> Date: Wed, 13 May 2009 13:48:34 +0100 From: Stuart Monteith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090403 SeaMonkey/1.1.16 MIME-Version: 1.0 To: kato-spec@incubator.apache.org Subject: JavaStackFrame/JavaLocation local variable support Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+bl6HlTLyrJqRoJH3E3GeYlh0KYDFjQ5Mkbga jJ10QqkgukGzMAn5XbzGJrOmk+6LqGKnxWh9McfBKOI0iTK42P Bi4GN+NaO8IfFXHyPZf0Jn4Akw1Mg7P X-Virus-Checked: Checked by ClamAV on apache.org Hello, With Steve's work on JVMTI/python coming along, the issue of what to do about local methods is coming up. Currently there is no means to determine the names and values of local variables through the current API. The most obvious way of implementing this is to have the API do all of the processing by exposing the variables as name and value pairs. For example: interface JavaStackFrame { List getLocalVariables(); } where: interface LocalVariable { String getName(); Object getValue(); } Where the value is a JavaObject, or an boxed primitive. The other extreme is for the necessary information to be made available for the callers of the API to generate this information themselves. This would mean properly exposing: Program Counter - currently we have JavaLocation.getAddress(), which is an address in memory, rather than a bytecode program counter. For JITted frames we'd still need the bytecode program counter. Local variable table - this is to determine which variables there are, their types and their indexes into the local variable array Local variable array - the contents of the local variables need to be exposed, and their proper types should be returnable (JavaObject, int, etc). Doing it that way might be beneficial for more user stories, there is more information available to reconstruct the class file, for instance. There is also the small matter of what to do when the local variable table is not available. When the API exposes all that it knows the values might still be retrievable, although I have my doubts as to how useful that would be if you don't know the types. Thoughts? Stuart