Browse Prior Art Database

Attachment to a running JVM: Support for symbolic name and load addresses for previously generated code

IP.com Disclosure Number: IPCOM000028799D
Original Publication Date: 2004-Jun-01
Included in the Prior Art Database: 2004-Jun-01
Document File: 1 page(s) / 30K

Publishing Venue

IBM

Abstract

After attaching to a running Java (*) Virtual Machine (JVM), the profiler/debugger may need to get information about already generated code. For example, for Time Profiling (tprof) and Instruction Trace (ITrace), it is critical to know the address and names of JITed methods. It is also important to know the address and names of other generated code, such as, built-ins or on some JVMs, the interpreter itself involves copied and modified code. This information is required to convert addresses to symbolic names. We describe two methods of getting this critical "catchup" data so that the full ITrace & tprof functionality can be realized even when the profiler is started later than the application.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 89% of the total text.

Page 1 of 1

Attachment to a running JVM : Support for symbolic name and load addresses for previously generated code

Solution I)

An interface could be supplied for the profiler to use which has the JVM/JIT send events identifying all the previously generated code. This could be implemented by enabling the JVM to maintain a queue of events for exactly this information. It has the advantage of simplicity. It has the disadvantage of requiring additional space for each event, which could be a problem for JVMs that continue to be used week after week. However, it is likely that the work mix repeatability along with caching techniques will contain this space to a reasonable size.

Solution II)

The JVM/JIT keeps internal tables which allow for the dumping of the required information. With this approach, the deleted entries are removed from the tables as the deletion occurs and the overhead reflects the state of the system. For many cases, this is simply traversing already existing tables or entails a slight modifications of existing tables.

Knowledge of the names of the methods could be determined by call backs. As a method, not recognized by the profiler, is sent to the profiler, the profiler could request the name information from the JVM. The JVM could provide the information related to the entire class or just for the specified method. At any rate, the profiler could keep the name information for each method in a hash table to avoid having to call the JVM more than once for the...