Hi Maynard, I'm currently looking at your changes. At first glance they look good.
I could open a simple core file which contained both, interpreted and compiled frames: $ jstack ./images/j2sdk-image/bin/java core.7034 ... Thread 7035: (state = IN_VM) - sun.misc.Unsafe.putAddress(long, long) @bci=0 (Interpreted frame) - Crash.crashIt(sun.misc.Unsafe, int) @bci=10, line=8 (Interpreted frame) - Crash.doIt() @bci=45, line=23 (Compiled frame) - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame) - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=100, line=62 (Interpreted frame) - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6, line=43 (Interpreted frame) - java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) @bci=56, line=498 (Interpreted frame) - Crash.main(java.lang.String[]) @bci=32, line=31 (Interpreted frame) The one thing that doesn't currently work is "jstack -m" (i.e. "mixed mode" for java and native frames). Are you aware of this? Regarding your "test.java" example - how do you use it? If I just attach with jstack to the Java process which runs "test.java" I get the correct stack trace of all threads. But I think that's actual no SA-functionality but a VM-feature (the same that can be triggered by sending kill -SIGQUIT to java process). If I attach with "jstack -F" I see the problems you mentioned. First I didn't saw any frame at all which confused me but then I also saw the two cases mentioned by you. I'll need to have a closer look what happens. Regards, Volker On Fri, Nov 14, 2014 at 7:09 PM, Maynard Johnson <mayna...@us.ibm.com> wrote: > When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core > file, they fail with the following runtime exception: > > OS/CPU combination linux/ppc64 not yet supported > > I will post a patch set that adds this support. The patch set consists of > the following patches: > > PATCH 1/2: Updates to non-Java files to support linux/ppc64 Hotspot SA with > core files > > PATCH 2/2: New PPC64 class files (and updates to generic files) to support > linux/ppc64 Hotspot SA with core files > > These two patches apply cleanly to a November 13 pull of the jdk9-dev > upstream sources. > > ------------ > Open issues: > ------------ > 1) The jstack tool does not print a stack entry for the 'main()' method of > the Java > workload (attached) under test. For example: > > (Note: Addresses and method signatures elided for brevity.) > > Thread 24358: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., > Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled > frame) > ==> (Expect an entry for test.main() here) > > 2) The jstack tool sometimes prints what appears to be two complete stacks > for the Java workload. For example: > > Thread 24779: (state = IN_JAVA, current Java SP = null > ) > - java.lang.String.getChars(...) @bci=58, line=814, pc=..., > Method*=... (Compiled frame; ... imprecise) > - test.run_test() @bci=80, line=33, pc=..., Method*=... (Compiled > frame) > - test.get_my_chars(...) @bci=39, line=15, pc=..., Method*=... > (Compiled frame) > - test.run_test() @bci=92, line=34, pc=..., Method*=... (Compiled > frame) > > Again, the 'test.main' method is missing, but there's also the anomaly > of the > test.run_test' method showing up twice in the stack, implying that it > is called > by 'test.get_my_chars' at line 15. But that that is not accurate. In > fact, run_test > does call String.getChars at line 33 *and* it calls test.get_my_chars > at line 34 -- > but these are totally distinct call graphs. Somehow, we are seeing > these two distinct > stacks in the core file, which seems impossible. > > --------- > > Any help offered on these two open issues would be greatly appreciated. > > -Maynard
