On 12/03/2014 02:40 AM, Volker Simonis wrote: > On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson <[email protected]> wrote: >> On 12/02/2014 11:45 AM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> did you intentionally answered only to me or can we take the discussion >>> back to the mailing list? >> >> Yes, it was intentional. I figured that if we did indeed have some >> functional problems to fix, >> we may want to discuss off-list until we agree we're ready for full patch >> review. I apologize if >> that's not following normal process. Let me know how and when you'd like me >> to bring this discussion >> back to the list. Hi, Volker, You've answered all of my concerns -- thanks for your patience. Can you please let me know the process for getting the web review moving?
>> >>> Please find further comments inline: >>> >>> On Tue, Dec 2, 2014 at 12:16 AM, Maynard Johnson <[email protected] >>> <mailto:[email protected]>> wrote: >>>> On 11/25/2014 12:40 PM, Volker Simonis wrote: >>>>> Hi Maynard, >>>>> >>>>> so here finally comes my version of your change. I've tested 'jstack' >>>>> with no, '-F' and '-m' flags on PIDs and core files on BigEndian >>>>> Linux/PPC64 and it seems to work quite stable now. I've also done some >>>>> basic tests with 'jmap' with no, '-histo' and '-F' flags and 'jinfo'. >>>> Hi, Volker, >>>> Thank you very much for your help with the patch I posted. >>>> I tried out your new patch and my results aren't quite as expected. I >>>> wonder >>>> if I need to update my source tree as it's a few weeks old by now. Anyway, >>>> running 'jstack `which java` core', I usually get something like the >>>> following >>>> for the thread that's running the actual java app code: >>> >>> I've cloned today a fresh copy of jdk9-dev, applied the patch and build the >>> images. Everything worked as expected. Could you please also try with a >>> fresh version of jdk9-dev. >> >> OK, I did the same today. >> >>> >>>> >>>> --------------------------------- >>>> Thread 22585: (state = IN_JAVA, current Java SP = null >>>> ) >>>> - test.main(java.lang.String[]) @bci=100, line=54, pc=0x00003fff8800953c, >>>> Method*=0x00003fff7dc00998 (Interpreted frame) >>>> --------------------------------- >>>> >>>> As you can see, there's no compiled frame output where I expect I should >>>> see something. >>>> I get this pretty consistently on both BE and LE. I also see the same >>>> thing running 'jstack -F <pid>' >>>> on BE. >>> >>> That's not unusual. The problem with your example is that it above >>> test.main all the other methods are compiled AND inlined. That means that >>> there's just one physical frame above test.main. If the stack tracing >>> routine can't make sense of the first frame, in not only skips that frame, >>> but also all the virtual java frames which are contained inside this >>> physical frame. You can try to run your example with "-XX:-Inline" to avoid >>> inlining and see deeper stack traces. >> >> Thanks for the tip. Using "-XX:-Inline" does show more stack. Sometimes the >> stack looks like following: >> >> --------------------------------- >> Thread 18959: (state = IN_JAVA) >> - test.get_my_chars(int, int, char[], java.lang.String, int) @bci=34, >> line=14 (Compiled frame; information may be imprecise) >> - test.run_test() @bci=63, line=31 (Compiled frame) >> - test.main(java.lang.String[]) @bci=100, line=54 (Interpreted frame) >> --------------------------------- >> >> But usually the stack just has "main" and "run_test", always with the same >> line numbers, whether or not get_my_chars is included in the stack. But as >> I mentioned in my earlier note, line #31 in run_test is the first line of a >> for-loop, not the (expected) call to get_my_chars. >> > > Again, PC to line/BCImapping is only precise at safepoints. There's no > chance to get this 100% right. But that's the same on all > architectures. If you run with -XX:+PrintInlining you will what has > been inlined which may help to interprete the missing parts in a stack > trace which was not taken at a safepoint. > >> In the approximate 10 times that I re-ran my test with the "-XX:-Inline" >> (sometimes killing it with SIGSEGV to get a core file; sometimes using >> 'jstack -F'), I twice got an NPE: >> >> java.lang.NullPointerException >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:88) >> at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45) >> . . . >> >> Line 88 in StackTrace.java is >> >> tty.print(" - " + method.externalNameAndSignature() + >> " @bci=" + vf.getBCI()); >> >> I'll work on debugging this. >> > > Yes, that should be fixed. Maybe we need some more checks if 'method' > and 'vf' are valid. In fact, I'm consistently seeing the same NPE on x86 when I run the java app with "-XX:-Inline" and then do 'jstack -F <pid>'. Do you know if there's a bug report open already for this? The jdk9 source on my x86 system was a couple months (or so) old, so I wanted to see if this still fails with current upstream code. I refreshed my source tree (via get_source.sh) and tried to rebuild it, but I got a compile failure. I imagine someone else is already working on that. -Maynard > [snip]
