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