Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero

[Maynard Johnson]

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 <maynardj at 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.simonis at 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.daugherty at 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 <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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>