ARM: Support for JVMTI notifications from JIT compiler on code generation

[Andrew Dinn]

Attached is the latest version of this patch tweaked to remedy faults
noted in previous comments and in the light of experience using it to
generate oprofile output for SPECjvm2008 runs.

Java<->VM<->Native transitions:

The tests revealed the purpose of the JvmtiJavaThreadEventTransition
included in the new ARM JvmtiExport API method. It marks thread
transitions from VM code to native (JVMTI agent) library code. It turns
out that the Interpreter and, hence, ARM JIT*** are run in a thread
marked as running in Java code. So, before/after calling into the JVMTI
libraries the JIT compiler code constructs a ThreadInVMfromJava which
performs a Java to/from VM thread transition.

**** n.b. this differs from the conventional OpenJDK setup where the
interpreter runs 'in Java' and queues compile tasks for execution by a
compiler thread which runs 'in VM'.

ARM JIT Stub/Handler code:

The ARM JIT generates some stub/handler code when libjvm.so is loaded
which really needs notifying to agents. With the previous patch details
of this code were not being passed on to the agent. As a consequence the
profile results included anonymous entries showing execution of the stub
code. Unfortunately, at the point during bootstrap where libjvm.so is
loaded there is no Java thread present and agents certainly are not loaded.

So, this version of the patch is modified to track the start and end
addresses for the whole block of stub code for later notification. An
initialization routine is called the first time a method is generated
which i) allocates the address to bci map buffer and ii) posts a
dynamic_generate event for the stub region. Looking at profiler ouptut
the stub code block accounts for only a small percentage of the executed
code so at present it does not seem worth recording and notifying
separate address ranges for the individual stub/handler routines.

A few Java anon entries still appear in the profiler listing but these
appear to be for processes/threads other than the one running the tests
used to exercise the patch. So, it appears that this patch accounts for
all code generated in-process by the ARM JIT.

regards,


Andrew Dinn
-----------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120501/0151ac0a/patch.txt