After a quick look I can say that at least for the "flush_icache_stub" and "verify_oop" cases we indeed generate no code. Other platforms like x86 for example generate code for instruction cache flushing. The starting address of this code is saved in a function pointer and called if necessary. On PPC64 we just save the address of a normal C-funtion in this function pointer and implement the cache flush with the help of inline assembler in the C-function. However this saving of the C-function address in the corresponding function pointer is still done in a helper method which triggers the creation of the JvmtiExport::post_dynamic_code_generated_internal event - but with zero size in that case.
I agree that it is questionable if we really need to post these events although they didn't hurt until know. Maybe we can remove them - please let me think one more night about it:) Regards, Volker On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis <volker.simo...@gmail.com> wrote: > 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 >>> >>> >>> >>
