Browse Prior Art Database

Attachment to a running JVM: Support of dynamic call stack generation Disclosure Number: IPCOM000028800D
Original Publication Date: 2004-Jun-01
Included in the Prior Art Database: 2004-Jun-01
Document File: 1 page(s) / 30K

Publishing Venue



After attaching to a running Java (*) Virtual Machine (JVM), the profiler/debugger may need to get events from JITed code, specifically JITed method entries and exits.

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

Page 1 of 1

Attachment to a running JVM : Support of dynamic call stack generation

S olution I) Always generate the required instrumentation when JITing a method. The instrumentation could have a single profiler-enabled test. If the profiler is enabled, then additional check(s) can be made for specific event(s) enablement. The profiler-enabled check would be dynamic in that the profiler may or may not be attached. This approach is very CPU efficient in the no profiler case. However, it does increase the size of each JITed method. This increase in size could be made to be relatively small by using a common instrumentation routine. This instrumentation routine could use thread specific data to identify the method-block of the method currently being executed which would be used to perform the required instrumentation.

Solution II) Maintain a table which identifies the load address of each JITed method. When the profiler is attached and the request for the JITed method entry/exit event(s) are enabled, prior to actually enabling the event(s), a call is made to the JIT which produces the instrumentation required for each of the JITed methods, so that the methods are modified to branch to/from the instrumentation as required. Once all of the JITed methods are instrumented, the event(s) are then enabled.

Solution III) Some methods are reJITed with the required instrumentation, some methods are updated in place to go to the newly generated instrumentation. Alternatively, the JVM/JIT...