Hi Maynard, I really apologize that I've somehow missed your first message. ppc-aix-port-dev was the right list to post to.
I'll analyze this problem instantly and let you know why we post this zero-code size events. Regards, Volker PS: really great to see that somebody is working on oprofile/OpenJDK integration! On Wed, Jul 2, 2014 at 6:28 PM, Daniel D. Daugherty <daniel.daughe...@oracle.com> wrote: > 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 <mayna...@us.ibm.com> >> To: ppc-aix-port-...@openjdk.java.net <ppc-aix-port-...@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 >> >> >> >
