'Re: PowerPC: core file option not available with serviceability tools'

[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:       Maynard Johnson <maynardj () us ! ibm ! com>
Date:       2014-09-29 22:42:14
Message-ID: 5429E046.8030003 () us ! ibm ! com
[Download RAW message or body]

On 07/09/2014 12:38 PM, Volker Simonis wrote:
> 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.
Hi, Volker.  Knock, knock.  :-)
I was preoccupied for a while this summer rolling out the latest release of oprofile \
(for which I'm the maintainer), but am now coming back to this task. I've implemented \
what I believe are all of the necessary ppc64-specific Java files to enable the \
jstack and jmap tools to work on core files.  I've also updated \
hotspot/agent/src/os/linux/LinuxDebuggerLocal.c to implement the accumulation of \
register data on ppc64 vi ptrace.  But now I've run into a problem I need help with. 

When I run jstack on my POWER7 system, it gets stuck in a loop in \
sun.jvm.hotspot.tools.StackTrace::run.  There's an inner for-loop there where \
cur.getLastJavaVFrameDbg() is called ('cur' is a JavaThread). For the first \
JavaThread, we do return from getLastJavaVFrameDbg(), just as we do when running \
jstack on my Intel laptop.  But for the second JavaThread, we never return from \
getLastJavaVFrameDbg() on ppc64.  I believe the root of the problem is in my new  \
sun.jvm.hotspot.runtime.ppc64.PPC64Frame class. The getLastJavaVFrameDbg method calls \
getCurrentFrameGuess, which is implemented in the new \
sun.jvm.hotspot.runtime.linux_ppc64.LinuxPPC64JavaThreadPDAccess class. In both ppc64 \
and x86, this first level xxxCurrentFrameGuess object is instantiated with a 'pc' \
value of null, so getCurrentFrameGuess then new's up a xxxFrame object, passing in \
the SP and FP, but no PC. The implementation of the PPC64Frame(Address,Address) \
constructor is currently identical to the X86Frame cons!  tructor, b
ut is almost certainly incorrect. In this constructor, the 'pc' is set as follows:
         this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize());

This works fine on X86, but not on ppc64. But I'm not understanding how this even \
works on X86. From what I understand, the data below the stack pointer on X86 is the \
"red zone". How is that being used as a pc? But more importantly, do you know how I \
can ascertain what the 'pc' value should be for ppc64?

Thanks in advance for any assistance you can give.

-Maynard

> 
> 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 that 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(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@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
> > > > 
> > > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic