[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: PowerPC: core file option not available with serviceability tools
From:       Volker Simonis <volker.simonis () gmail ! com>
Date:       2014-07-09 17:38:12
Message-ID: CA+3eh12adTVeSQsRVOgZDa=z-zsjUhLePmT9bauvoacrUFjdrw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jul 9, 2014 at 3:45 PM, Maynard Johnson <maynardj@us.ibm.com> wrote=
:
> On 07/04/2014 10:59 AM, Volker Simonis wrote:
>> Hi Maynard,
>>
>> we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and
>> AIX (we have other proprietary servicibility tools). Because of that
>> (and because SA isn't specified by the SE specification) porting the
>> SA agent was no top priority until now. But there are no technical
>> reasons why it should not work (it's just a lack of  resources). Of
>> course contributions are always highly welcome:)
>>
>> That said, the SA agent library and jar file actually gets build. If
>> you do a complete build you'll find them under:
>>
>> hotspot/linux_ppc64_compiler2/generated/sa-jdi.jar
>> hotspot/linux_ppc64_compiler2/{product,fastdebug,debug}/libsaproc.so
>>
>> in the build directory. They are just not copied into the jdk
>> workspace and the created images because they don't work out of the
>> box.
>>
>> The following two patches for the jdk9 top-level and hotspot
>> repositories respectively should fix the build such that the agent
>> files will be correctly copied into the images.
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/sa_toplevel
>> http://cr.openjdk.java.net/~simonis/webrevs/sa_hotspot/
>>
>> They will get you to the point where for example 'jstack' will run up
>> to the following point:
> Ok, great.  This should be enough to get me started.  I should have time =
to begin on this later this week or early next week.

Hi Maynard,

great to welcome you in the ppc64 porting team:)

> I may come knocking at your "door" for some occasional help, but I'll try=
 to keep that to a minimum.

Please feel free to ask any questions. The OpenJDK project and
especially the HotSpot part are known to take some getting used to.

> I was wondering if a bug report should be opened in JBS, just to record t=
hat the issue is being worked.  Thoughts?

I have opened "8049715: PPC64: First steps to enable SA on
Linux/PPC64" (https://bugs.openjdk.java.net/browse/JDK-8049715) for
the patch which I sent you with the last mail. I've already sent out
webrevs for that change and hopefully it will be fixed within the next
few days.

For the actual port of the ppc64-specific stuff I opened bug "8049716
PPC64: Implement SA on Linux/PPC64"
(https://bugs.openjdk.java.net/browse/JDK-8049716). I can also help
with hosting the webrevs, once you have a running version.

Regards,
Volker

>
> -Maynard
>>
>>> images/j2sdk-image/bin/jstack ./jdk/bin/java core.13547
>> Attaching to core core.13547 from executable ./jdk/bin/java, please wait=
...
>> WARNING: Hotspot VM version
>> 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00 does not match with
>> SA version 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00. You may
>> see unexpected results.
>> Debugger attached successfully.
>> Server compiler detected.
>> JVM version is 1.9.0-internal-debug-d046063_2014_07_04_11_46-b00
>> Deadlock Detection:
>>
>> Exception in thread "main" java.lang.reflect.InvocationTargetException
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI=
mpl.java:62)
>>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA=
ccessorImpl.java:43)
>>     at java.lang.reflect.Method.invoke(Method.java:484)
>>     at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
>>     at sun.tools.jstack.JStack.main(JStack.java:106)
>> Caused by: java.lang.ExceptionInInitializerError
>>     at sun.jvm.hotspot.runtime.VM.getThreads(VM.java:610)
>>     at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.j=
ava:54)
>>     at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.j=
ava:39)
>>     at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62)
>>     at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
>>     at sun.jvm.hotspot.tools.JStack.run(JStack.java:66)
>>     at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
>>     at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
>>     at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
>>     at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
>>     ... 6 more
>> Caused by: java.lang.RuntimeException: OS/CPU combination linux/ppc64
>> not yet supported
>>     at sun.jvm.hotspot.runtime.Threads.initialize(Threads.java:97)
>>     at sun.jvm.hotspot.runtime.Threads.access$000(Threads.java:42)
>>     at sun.jvm.hotspot.runtime.Threads$1.update(Threads.java:52)
>>     at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:=
394)
>>     at sun.jvm.hotspot.runtime.Threads.<clinit>(Threads.java:50)
>>     ... 16 more
>>
>> And that's the point where I was saying that "contributions are always
>> highly welcome:)"
>>
>> Now all the Linux/PPC64 specific class under
>> hotspot/agent/src/share/classes/ would have to be implemented (e.g.
>> sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess). Are you
>> interested in contributing to this project?
>>
>> Regards,
>> Volker
>>
>> PS: I cc-ed serviceability-dev because I remember that they started a
>> poll a while ago about who is using the SA tools. I'm therefore not
>> quite sure what's the current status and what are the future plan for
>> these libraries.
>>
>>
>> On Thu, Jul 3, 2014 at 9:04 PM, Maynard Johnson <maynardj@us.ibm.com> wr=
ote:
>>> Hi, all,
>>> On my Intel laptop, I note that certain jdk9 serviceability tools -- js=
tack, jmap, jsadebugd -- have an option to pass a core file instead of a pr=
ocess ID; for example:
>>>
>>>         $ jstack -h
>>>         Usage:
>>>             jstack [-l] <pid>
>>>                 (to connect to running process)
>>>             jstack -F [-m] [-l] <pid>
>>>                 (to connect to a hung process)
>>>             jstack [-m] [-l] <executable> <core>
>>>                 (to connect to a core file)
>>>             jstack [-m] [-l] [server_id@]<remote server IP or hostname>
>>>                 (to connect to a remote debug server)
>>>
>>> But on my PowerLinux box, the core file option is missing from the usag=
e output.  I see that jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStac=
k.java requires the existence of sun.jvm.hotspot.tools.JStack for the core =
file option to be made available.  On my Intel system, the sun.jvm.hotspot.=
tools.JStack class is packaged in sa-jdi.jar in <jdk9Dev-install>/jvm/openj=
dk-1.9.0-internal/lib/.  But the sa-jdi.jar is missing on PowerPC.  Is ther=
e a technical reason for this or is it an oversight?
>>>
>>> The jsadebugd tool does not run at all on PowerLinux; it gets the follo=
wing error:
>>>
>>>         Error: Could not find or load main class sun.jvm.hotspot.jdi.SA=
DebugServer
>>>
>>> On my Intel system, the SADebugServer class is packaged in the sa-jdi.j=
ar mentioned above.
>>>
>>> I've spent the past day or so looking at makefiles until I'm cross-eyed=
, but haven't yet found where the issue might be.  Any tips would be apprec=
iated.
>>>
>>> Thanks.
>>> -Maynard
>>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]