Adding the Serviceability team to the thread since JVM/TI is owned
by them...
Dan
On 7/2/14 10:15 AM, Maynard Johnson wrote:
> Cross-posting to see if Hotspot developers can help.
>> -Maynard
>>> -------- Original Message --------
> Subject: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero
> Date: Wed, 25 Jun 2014 10:18:17 -0500
> From: Maynard Johnson <maynardj at us.ibm.com>
> To: ppc-aix-port-dev at openjdk.java.net <ppc-aix-port-dev at openjdk.java.net>
>> Hello, PowerPC OpenJDK folks,
> I am just now starting to get involved in the OpenJDK project. My goal is to ensure that the standard serviceability tools and tooling (jdb, JVMTI, jmap, etc.) work correctly on the PowerLinux platform. I selected JVMTI to start with since I have some experience from a client perspective with the JVMTI API. An OSS profiling tool for which I am the maintainer (oprofile) provides an agent library that implements the JVMTI API. Using this agent library to profile Java apps on my Intel-based laptop with OpenJDK (using various versions, up to current jdk9-dev) works fine. But the same profiling scenario attempted on my PowerLinux box (POWER7/Fedora 20) fails miserably.
>> The oprofile agent library registers for callbacks for CompiledMethodLoad, CompiledMethodUnload, and DynamicCodeGenerated. In the callback functions, it writes information about the JVMTI event to a file. After profiling completes, oprofile's post-processing phase involves interpreting the information from the agent library's output file and generating an ELF file to represent the JITed code. When I profile an OpenJDK app on my Power system, the post-processing phase fails while trying to resolve overlapping symbols. The failure is due to the fact that it is unexpectedly finding symbols with code size of zero overlapping at the starting address of some other symbol with non-zero code size. The symbols in question here are from DynamicCodeGenerated events.
>> Are these "code size=0" events valid? If so, I can fix the oprofile code to handle them. If they're not valid, then below is some debug information I've collected so far.
>> ----------------------------
>> I instrumented JvmtiExport::post_dynamic_code_generated_internal (in hotspot/src/share/vm/prims/jvmtiExport.cpp) to print a debug line when a symbol with code size of zero was detected and then ran the following command:
>> java -agentpath:<jdk9-install-dir>/jvm/openjdk-1.9.0-internal/demo/jvmti/CodeLoadInfo/lib/libCodeLoadInfo.so -version
>> The debug output from my instrumentation was as follows:
>> Code size is ZERO!! Dynamic code generated event sent for flush_icache_stub; code begin: 0x3fff68000080; code end: 0x3fff68000080
> Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68000a90; code end: 0x3fff68000a90
> Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600
> Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600
> Code size is ZERO!! Dynamic code generated event sent for throw_exception; code begin: 0x3fff68016600; code end: 0x3fff68016600
> Code size is ZERO!! Dynamic code generated event sent for verify_oop; code begin: 0x3fff6801665c; code end: 0x3fff6801665c
> openjdk version "1.9.0-internal"
> OpenJDK Runtime Environment (build 1.9.0-internal-mpj_2014_06_18_09_55-b00)
> OpenJDK 64-Bit Server VM (build 1.9.0-internal-mpj_2014_06_18_09_55-b00, mixed mode)
>>> I don't have access to an AIX system to know if the same issue would be seen there. Let me know if there's any other information I can provide.
>> Thanks for the help.
>> -Maynard
>>>