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. Hi, Volker, Just checking on the status of this bug. Thanks.
-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 >>>>>> >>>>>> >>>>>> >>>>> >>> >>
