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:
> 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(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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.java:54)
at sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java: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 <mayna...@us.ibm.com> wrote:
> Hi, all,
> On my Intel laptop, I note that certain jdk9 serviceability tools -- jstack,
> jmap, jsadebugd -- have an option to pass a core file instead of a process
> 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 usage
> output. I see that
> jdk9-dev/jdk/src/share/classes/sun/tools/jstack/JStack.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/openjdk-1.9.0-internal/lib/.
> But the sa-jdi.jar is missing on PowerPC. Is there a technical reason for
> this or is it an oversight?
>
> The jsadebugd tool does not run at all on PowerLinux; it gets the following
> error:
>
> Error: Could not find or load main class
> sun.jvm.hotspot.jdi.SADebugServer
>
> On my Intel system, the SADebugServer class is packaged in the sa-jdi.jar
> 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 appreciated.
>
> Thanks.
> -Maynard
>
