PowerPC: core file option not available with serviceability tools

[Volker Simonis]

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