On 07/07/2014 10:51 AM, Volker Simonis wrote: > Hi Maynard, > > I've opened bug "PPC64: Don't use StubCodeMarks for zero-length stubs" > (https://bugs.openjdk.java.net/browse/JDK-8049441) for this issue. > Until it is resolved in the main code line, you can use the attached > patch to work around the problem. Thanks. The patch does indeed resolve the problem. Now oprofile can properly handle the JVMTI events and can also resolve samples in JITed code to the associated Java methods. :-)
-Maynard > > Regards, > Volker > > > On Mon, Jul 7, 2014 at 4:18 PM, Maynard Johnson <mayna...@us.ibm.com> wrote: >> On 07/02/2014 01:21 PM, Volker Simonis wrote: >>> 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:) >> Any further thoughts on this, Volker? Thanks. >> >> -Maynard >>> >>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>> >>
