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

[Volker Simonis]

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.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
>>>
>>>
>>>
>>