From maynardj at us.ibm.com Wed Dec 3 18:20:14 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 03 Dec 2014 12:20:14 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E4DE6.30305@us.ibm.com> Message-ID: <547F545E.7090500@us.ibm.com> On 12/03/2014 02:24 AM, Volker Simonis wrote: > Hi Maynard, > > if you don't mind please post the next mail to the mailing list > thread. I think these problems and discussions may be helpfull for > others as well (e.g. people doing another port). > > On Wed, Dec 3, 2014 at 12:40 AM, Maynard Johnson wrote: >> On 12/01/2014 05:16 PM, Maynard Johnson 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: >>> >>> --------------------------------- >>> 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 ' >>> on BE. But unfortunately, neither 'jstack -F ' nor 'jmap ' are working at all on LE right now; >>> instead, I get the following error (which I'm investigating): >>> >>> Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process >> Hi Volker, >> I discovered that the hotspot debugger's call to ptrace was failing with errno of EPERM. This doesn't make sense >> to me since I'm running both the java app session and the 'jstack -F' session under my normal user account. > > If you're running on Debian/Ubuntu it is probably this issue: > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection > > which can be solved by doing: > > echo 0 > /proc/sys/kernel/yama/ptrace_scope Yes, that was the issue. Thanks for the tip! > > or set ptrace_scope to 0 in /etc/sysctl.d/10-ptrace.conf > > >> But when I ran the 'jstack -F' under root, it worked -- sort of. I get the following stack: >> >> Thread 44376: (state = IN_JAVA) >> - java.lang.String.getChars(int, int, char[], int) @bci=1, line=805 (Compiled frame; information may be imprecise) >> - test.main(java.lang.String[]) @bci=100, line=54 (Interpreted frame) >> >> Line #54 is a call to test.run_test, so I expected to see that in the stack (I was running the test java app with >> "-XX:-Inline"). >> > > I don't think we will ever manage to get this 100% correct. The > problem is that Java stacks are only guaranteed to be walkable at > safepoints. That's what happens when we use plain jstack. 'jstack -F' > or jstak on a core file may catch the threads in a state where sp/pc > are in an inconsistent state. I don't think there's much we can do > about it. I think the corresponding output on Linux/x86 isn't perfect > either. Yes, indeed. I looked more closely at my x86 stack output, and I see what you mean. -Maynard > >> I'll see if I can make more progress tomorrow. >> >> -Maynard >>> >> [snip] >> > From maynardj at us.ibm.com Wed Dec 3 18:33:38 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 03 Dec 2014 12:33:38 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> Message-ID: <547F5782.1060800@us.ibm.com> On 12/03/2014 02:40 AM, Volker Simonis wrote: > On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson 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 > 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 ' >>>> 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 '. 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] From volker.simonis at gmail.com Wed Dec 3 18:43:45 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 3 Dec 2014 19:43:45 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5782.1060800@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> Message-ID: On Wed, Dec 3, 2014 at 7:33 PM, Maynard Johnson wrote: > On 12/03/2014 02:40 AM, Volker Simonis wrote: >> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson 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 > 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 ' >>>>> 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 '. 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 Just as a short note (I'll answer all the other questions tomorrow). You should call 'bash common/bin/hgforest.sh pull -u' in the top level repositoy for updating the whole forest. "get_source.sh" will just fetch a new clone and copy it over the old version. This may be the source of your your build problem because it may leave old files in your workspace. > working on that. > > -Maynard >> > [snip] > From maynardj at us.ibm.com Wed Dec 3 18:55:03 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Wed, 03 Dec 2014 12:55:03 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5782.1060800@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> Message-ID: <547F5C87.7080803@us.ibm.com> On 12/03/2014 12:33 PM, Maynard Johnson wrote: > On 12/03/2014 02:40 AM, Volker Simonis wrote: >> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>> 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: [snip] >>> >>> 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 '. 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. Never mind . . . The compile failure was due to a conflict between a local change I made in one of the files and a change from upstream. I fixed it and the current upstream source builds fine on x86 now. However, the above-mentioned NPE still occurs most of the time. -Maynard > > -Maynard >> > [snip] > From volker.simonis at gmail.com Thu Dec 4 08:16:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 09:16:52 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5B88.10703@redhat.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E4DE6.30305@us.ibm.com> <547F545E.7090500@us.ibm.com> <547F5B88.10703@redhat.com> Message-ID: On Wed, Dec 3, 2014 at 7:50 PM, Andrew Haley wrote: > On 12/03/2014 06:20 PM, Maynard Johnson wrote: >>> If you're running on Debian/Ubuntu it is probably this issue: >>> > >>> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection >>> > >>> > which can be solved by doing: >>> > >>> > echo 0 > /proc/sys/kernel/yama/ptrace_scope >> Yes, that was the issue. Thanks for the tip! > > Good Lord, is that the default on Ubuntu? Argh. :-( > Yes, all for the sake of security! Probably we won't be able to invoke gcc without any extra efforts in the near future and finally the shell will be banned :) > Andrew. > > From volker.simonis at gmail.com Thu Dec 4 08:20:28 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 09:20:28 +0100 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: <547F5C87.7080803@us.ibm.com> References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> <547F5C87.7080803@us.ibm.com> Message-ID: On Wed, Dec 3, 2014 at 7:55 PM, Maynard Johnson wrote: > On 12/03/2014 12:33 PM, Maynard Johnson wrote: >> On 12/03/2014 02:40 AM, Volker Simonis wrote: >>> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>>> 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: > [snip] >>>> >>>> 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 '. 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. > Never mind . . . The compile failure was due to a conflict between a local change I made in > one of the files and a change from upstream. I fixed it and the current upstream source builds > fine on x86 now. However, the above-mentioned NPE still occurs most of the time. > That's bad, but that seems to be another issue which should be fixed separately. If you have no more changes/addons compared to my last webrev I can offer to submit a new request for review on behalf of you so we finally get this in. We will need on more review from the serviceability team and a sponsor who will push the change for us. Regards, Volker > -Maynard >> >> -Maynard >>> >> [snip] >> > From maynardj at us.ibm.com Thu Dec 4 14:27:32 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Thu, 04 Dec 2014 08:27:32 -0600 Subject: [PATCH RFC 0/2] Add linux/ppc64 support for Hotspot serviceability agent to read core files In-Reply-To: References: <54664554.4060309@us.ibm.com> <546A3768.20809@us.ibm.com> <546A82AE.6010703@us.ibm.com> <546E2D4D.7010103@us.ibm.com> <547CF6C9.1060304@us.ibm.com> <547E262F.8020601@us.ibm.com> <547F5782.1060800@us.ibm.com> <547F5C87.7080803@us.ibm.com> Message-ID: <54806F54.6050307@us.ibm.com> On 12/04/2014 02:20 AM, Volker Simonis wrote: > On Wed, Dec 3, 2014 at 7:55 PM, Maynard Johnson wrote: >> On 12/03/2014 12:33 PM, Maynard Johnson wrote: >>> On 12/03/2014 02:40 AM, Volker Simonis wrote: >>>> On Tue, Dec 2, 2014 at 9:50 PM, Maynard Johnson wrote: >>>>> 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: >> [snip] >>>>> >>>>> 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 '. 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. >> Never mind . . . The compile failure was due to a conflict between a local change I made in >> one of the files and a change from upstream. I fixed it and the current upstream source builds >> fine on x86 now. However, the above-mentioned NPE still occurs most of the time. >> > > That's bad, but that seems to be another issue which should be fixed separately. > > If you have no more changes/addons compared to my last webrev I can > offer to submit a new request for review on behalf of you so we > finally get this in. Yes, please -- and thanks again for all your help. -Maynard > We will need on more review from the > serviceability team and a sponsor who will push the change for us. > > Regards, > Volker > >> -Maynard >>> >>> -Maynard >>>> >>> [snip] >>> >> > From volker.simonis at gmail.com Thu Dec 4 17:50:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Dec 2014 18:50:46 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 Message-ID: Hi, I'd like to submit this webrev which adds support for the SA agent on Linux/PPC64 on behalf of Maynard Johnson who is the main author of the change: http://cr.openjdk.java.net/~simonis/webrevs/8049716 https://bugs.openjdk.java.net/browse/JDK-8049716 I have already reviewed and tested the change and from my side everything looks fine. The change touches quite some shared code but all of these changes are trivial and straight-forward (i.e. they just add Linux/PPC64 support with the help of '#ifdef's in C or yet another 'elseif' clause in Java). We need a second reviewer and a sponsor who can push this to the hotspot repository once the review is completed. Thank you and best regards, Volker From asmundak at google.com Thu Dec 4 19:15:25 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 4 Dec 2014 11:15:25 -0800 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: Message-ID: The changes for agent/src/os/linux/symtab.c b/agent/src/os/linux/symtab.c in http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break Linux/PPC64 little-endian: it uses ABIv2, which dropped function descriptors. So the preprocessor brackets in it should read #if defined(ppc64) && !defined(ABI_ELFv2) instead of just #if defined(ppc64) Sorry for the late notice. Sasha On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: > Hi, > > I'd like to submit this webrev which adds support for the SA agent on > Linux/PPC64 on behalf of Maynard Johnson who is the main author of the > change: > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > I have already reviewed and tested the change and from my side > everything looks fine. > > The change touches quite some shared code but all of these changes are > trivial and straight-forward (i.e. they just add Linux/PPC64 support > with the help of '#ifdef's in C or yet another 'elseif' clause in > Java). > > We need a second reviewer and a sponsor who can push this to the > hotspot repository once the review is completed. > > Thank you and best regards, > Volker From maynardj at us.ibm.com Thu Dec 4 23:43:38 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Thu, 04 Dec 2014 17:43:38 -0600 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: Message-ID: <5480F1AA.4010900@us.ibm.com> On 12/04/2014 01:15 PM, Alexander Smundak wrote: > The changes for agent/src/os/linux/symtab.c > b/agent/src/os/linux/symtab.c in > http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break > Linux/PPC64 little-endian: > it uses ABIv2, which dropped function descriptors. So the preprocessor > brackets in it should > read > #if defined(ppc64) && !defined(ABI_ELFv2) > instead of just > #if defined(ppc64) Hi, Alexander, I think this is actually fine everywhere except one place. The 'opd' variable will be set to something other than NULL at line 379 only if running on ppc64 BE. So in the rest of that function, opd is checked for non-null before using it. The only place where I think there may be a problem is at line 455: -------------------------- #if defined(ppc64) // On Linux/PPC64 the debuginfo files contain an empty file descriptor // section (i.e. '.opd' section) which makes the resolution of symbols // with the above algorithm impossible (we would need the have both, the // .opd section from the library and the symbol table from the debuginfo // file which doesn't match with the current workflow.) if (false) { #else // Look for a separate debuginfo file. if (try_debuginfo) { #endif -------------------------- Here I think we should do as you suggest: #if defined(ppc64) && !defined(ABI_ELFv2) -Maynard > > Sorry for the late notice. > Sasha > > On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >> Hi, >> >> I'd like to submit this webrev which adds support for the SA agent on >> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >> change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >> https://bugs.openjdk.java.net/browse/JDK-8049716 >> >> I have already reviewed and tested the change and from my side >> everything looks fine. >> >> The change touches quite some shared code but all of these changes are >> trivial and straight-forward (i.e. they just add Linux/PPC64 support >> with the help of '#ifdef's in C or yet another 'elseif' clause in >> Java). >> >> We need a second reviewer and a sponsor who can push this to the >> hotspot repository once the review is completed. >> >> Thank you and best regards, >> Volker > From asmundak at google.com Fri Dec 5 01:50:08 2014 From: asmundak at google.com (Alexander Smundak) Date: Thu, 4 Dec 2014 17:50:08 -0800 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <5480F1AA.4010900@us.ibm.com> References: <5480F1AA.4010900@us.ibm.com> Message-ID: You are correct, but there no need to have this code for LE at all. BTW, a bit on nitpicking in the same file: + String endian = System.getProperty("sun.cpu.endian"); + if (endian.equals("big")) + return true; + else + return false; can be rewirtten as return "big".equals(System.getProperty("sun.cpu.endian")); On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: > On 12/04/2014 01:15 PM, Alexander Smundak wrote: >> The changes for agent/src/os/linux/symtab.c >> b/agent/src/os/linux/symtab.c in >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >> Linux/PPC64 little-endian: >> it uses ABIv2, which dropped function descriptors. So the preprocessor >> brackets in it should >> read >> #if defined(ppc64) && !defined(ABI_ELFv2) >> instead of just >> #if defined(ppc64) > Hi, Alexander, > I think this is actually fine everywhere except one place. The 'opd' variable will be > set to something other than NULL at line 379 only if running on ppc64 BE. So in > the rest of that function, opd is checked for non-null before using it. The only > place where I think there may be a problem is at line 455: > > -------------------------- > #if defined(ppc64) > // On Linux/PPC64 the debuginfo files contain an empty file descriptor > // section (i.e. '.opd' section) which makes the resolution of symbols > // with the above algorithm impossible (we would need the have both, the > // .opd section from the library and the symbol table from the debuginfo > // file which doesn't match with the current workflow.) > if (false) { > #else > // Look for a separate debuginfo file. > if (try_debuginfo) { > #endif > -------------------------- > > Here I think we should do as you suggest: > #if defined(ppc64) && !defined(ABI_ELFv2) > > -Maynard >> >> Sorry for the late notice. >> Sasha >> >> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>> Hi, >>> >>> I'd like to submit this webrev which adds support for the SA agent on >>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>> change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>> >>> I have already reviewed and tested the change and from my side >>> everything looks fine. >>> >>> The change touches quite some shared code but all of these changes are >>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>> Java). >>> >>> We need a second reviewer and a sponsor who can push this to the >>> hotspot repository once the review is completed. >>> >>> Thank you and best regards, >>> Volker >> > From maynardj at us.ibm.com Fri Dec 5 14:10:58 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Fri, 05 Dec 2014 08:10:58 -0600 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> Message-ID: <5481BCF2.9050501@us.ibm.com> On 12/04/2014 07:50 PM, Alexander Smundak wrote: > You are correct, but there no need to have this code for LE at all. Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file along with the "#if defined(ppc64)". > > BTW, a bit on nitpicking in the same file: > + String endian = System.getProperty("sun.cpu.endian"); > + if (endian.equals("big")) > + return true; > + else > + return false; > can be rewirtten as > return "big".equals(System.getProperty("sun.cpu.endian")); Right. A silly piece of coding there. :-/ -Maynard > > > On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>> The changes for agent/src/os/linux/symtab.c >>> b/agent/src/os/linux/symtab.c in >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>> Linux/PPC64 little-endian: >>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>> brackets in it should >>> read >>> #if defined(ppc64) && !defined(ABI_ELFv2) >>> instead of just >>> #if defined(ppc64) >> Hi, Alexander, >> I think this is actually fine everywhere except one place. The 'opd' variable will be >> set to something other than NULL at line 379 only if running on ppc64 BE. So in >> the rest of that function, opd is checked for non-null before using it. The only >> place where I think there may be a problem is at line 455: >> >> -------------------------- >> #if defined(ppc64) >> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >> // section (i.e. '.opd' section) which makes the resolution of symbols >> // with the above algorithm impossible (we would need the have both, the >> // .opd section from the library and the symbol table from the debuginfo >> // file which doesn't match with the current workflow.) >> if (false) { >> #else >> // Look for a separate debuginfo file. >> if (try_debuginfo) { >> #endif >> -------------------------- >> >> Here I think we should do as you suggest: >> #if defined(ppc64) && !defined(ABI_ELFv2) >> >> -Maynard >>> >>> Sorry for the late notice. >>> Sasha >>> >>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> I'd like to submit this webrev which adds support for the SA agent on >>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>> change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>> >>>> I have already reviewed and tested the change and from my side >>>> everything looks fine. >>>> >>>> The change touches quite some shared code but all of these changes are >>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>> Java). >>>> >>>> We need a second reviewer and a sponsor who can push this to the >>>> hotspot repository once the review is completed. >>>> >>>> Thank you and best regards, >>>> Volker >>> >> > From volker.simonis at gmail.com Fri Dec 5 15:01:33 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 16:01:33 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <5481BCF2.9050501@us.ibm.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: Hi Sasha, thanks for looking at this change. I'll incorporate your suggestions into the final version. I'm just waiting for one more review before preparing a new webrev. Regards, Volker On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: > On 12/04/2014 07:50 PM, Alexander Smundak wrote: >> You are correct, but there no need to have this code for LE at all. > Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file > along with the "#if defined(ppc64)". >> >> BTW, a bit on nitpicking in the same file: >> + String endian = System.getProperty("sun.cpu.endian"); >> + if (endian.equals("big")) >> + return true; >> + else >> + return false; >> can be rewirtten as >> return "big".equals(System.getProperty("sun.cpu.endian")); > Right. A silly piece of coding there. :-/ > > -Maynard >> >> >> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>> The changes for agent/src/os/linux/symtab.c >>>> b/agent/src/os/linux/symtab.c in >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>> Linux/PPC64 little-endian: >>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>> brackets in it should >>>> read >>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>> instead of just >>>> #if defined(ppc64) >>> Hi, Alexander, >>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>> the rest of that function, opd is checked for non-null before using it. The only >>> place where I think there may be a problem is at line 455: >>> >>> -------------------------- >>> #if defined(ppc64) >>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>> // section (i.e. '.opd' section) which makes the resolution of symbols >>> // with the above algorithm impossible (we would need the have both, the >>> // .opd section from the library and the symbol table from the debuginfo >>> // file which doesn't match with the current workflow.) >>> if (false) { >>> #else >>> // Look for a separate debuginfo file. >>> if (try_debuginfo) { >>> #endif >>> -------------------------- >>> >>> Here I think we should do as you suggest: >>> #if defined(ppc64) && !defined(ABI_ELFv2) >>> >>> -Maynard >>>> >>>> Sorry for the late notice. >>>> Sasha >>>> >>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>> change: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>> >>>>> I have already reviewed and tested the change and from my side >>>>> everything looks fine. >>>>> >>>>> The change touches quite some shared code but all of these changes are >>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>> Java). >>>>> >>>>> We need a second reviewer and a sponsor who can push this to the >>>>> hotspot repository once the review is completed. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>> >>> >> > From volker.simonis at gmail.com Tue Dec 9 18:10:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Dec 2014 19:10:52 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: Hi, can somebody from the serviceability team please review this webrev? http://cr.openjdk.java.net/~simonis/webrevs/8049716 https://bugs.openjdk.java.net/browse/JDK-8049716 The shared changes are really all trivial. Thanks, Volker On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: > Hi Sasha, > > thanks for looking at this change. > I'll incorporate your suggestions into the final version. > I'm just waiting for one more review before preparing a new webrev. > > Regards, > Volker > > > On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>> You are correct, but there no need to have this code for LE at all. >> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >> along with the "#if defined(ppc64)". >>> >>> BTW, a bit on nitpicking in the same file: >>> + String endian = System.getProperty("sun.cpu.endian"); >>> + if (endian.equals("big")) >>> + return true; >>> + else >>> + return false; >>> can be rewirtten as >>> return "big".equals(System.getProperty("sun.cpu.endian")); >> Right. A silly piece of coding there. :-/ >> >> -Maynard >>> >>> >>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>> The changes for agent/src/os/linux/symtab.c >>>>> b/agent/src/os/linux/symtab.c in >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>> Linux/PPC64 little-endian: >>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>> brackets in it should >>>>> read >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> instead of just >>>>> #if defined(ppc64) >>>> Hi, Alexander, >>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>> the rest of that function, opd is checked for non-null before using it. The only >>>> place where I think there may be a problem is at line 455: >>>> >>>> -------------------------- >>>> #if defined(ppc64) >>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>> // with the above algorithm impossible (we would need the have both, the >>>> // .opd section from the library and the symbol table from the debuginfo >>>> // file which doesn't match with the current workflow.) >>>> if (false) { >>>> #else >>>> // Look for a separate debuginfo file. >>>> if (try_debuginfo) { >>>> #endif >>>> -------------------------- >>>> >>>> Here I think we should do as you suggest: >>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>> >>>> -Maynard >>>>> >>>>> Sorry for the late notice. >>>>> Sasha >>>>> >>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>> Hi, >>>>>> >>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>> change: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>> >>>>>> I have already reviewed and tested the change and from my side >>>>>> everything looks fine. >>>>>> >>>>>> The change touches quite some shared code but all of these changes are >>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>> Java). >>>>>> >>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>> hotspot repository once the review is completed. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>> >>>> >>> >> From dmitry.samersoff at oracle.com Tue Dec 9 19:03:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 22:03:18 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: <54874776.2080303@oracle.com> Volker, I'll take a look at it. -Dmitry On 2014-12-09 21:10, Volker Simonis wrote: > Hi, > > can somebody from the serviceability team please review this webrev? > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > The shared changes are really all trivial. > > Thanks, > Volker > > > On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >> Hi Sasha, >> >> thanks for looking at this change. >> I'll incorporate your suggestions into the final version. >> I'm just waiting for one more review before preparing a new webrev. >> >> Regards, >> Volker >> >> >> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>> You are correct, but there no need to have this code for LE at all. >>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>> along with the "#if defined(ppc64)". >>>> >>>> BTW, a bit on nitpicking in the same file: >>>> + String endian = System.getProperty("sun.cpu.endian"); >>>> + if (endian.equals("big")) >>>> + return true; >>>> + else >>>> + return false; >>>> can be rewirtten as >>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>> Right. A silly piece of coding there. :-/ >>> >>> -Maynard >>>> >>>> >>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>> The changes for agent/src/os/linux/symtab.c >>>>>> b/agent/src/os/linux/symtab.c in >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>> Linux/PPC64 little-endian: >>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>> brackets in it should >>>>>> read >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> instead of just >>>>>> #if defined(ppc64) >>>>> Hi, Alexander, >>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>> place where I think there may be a problem is at line 455: >>>>> >>>>> -------------------------- >>>>> #if defined(ppc64) >>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>> // with the above algorithm impossible (we would need the have both, the >>>>> // .opd section from the library and the symbol table from the debuginfo >>>>> // file which doesn't match with the current workflow.) >>>>> if (false) { >>>>> #else >>>>> // Look for a separate debuginfo file. >>>>> if (try_debuginfo) { >>>>> #endif >>>>> -------------------------- >>>>> >>>>> Here I think we should do as you suggest: >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> >>>>> -Maynard >>>>>> >>>>>> Sorry for the late notice. >>>>>> Sasha >>>>>> >>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>> change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>> >>>>>>> I have already reviewed and tested the change and from my side >>>>>>> everything looks fine. >>>>>>> >>>>>>> The change touches quite some shared code but all of these changes are >>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>> Java). >>>>>>> >>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>> hotspot repository once the review is completed. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>> >>>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Wed Dec 10 11:22:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Dec 2014 21:22:27 +1000 Subject: AARCH64: 8064611: Changes to HotSpot shared code In-Reply-To: References: <54625D3D.4000007@redhat.com> <4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap> <54632ABA.5000706@redhat.com> <4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap> <54638FA0.8040204@redhat.com> <546572B8.9080005@oracle.com> <546A1EF5.6060607@redhat.com> <546A60C7.1070408@oracle.com> <546BF7F3.5020507@oracle.com> <546C0881.8050905@oracle.com> <546C1264.6090308@oracle.com> <546DF9D8.3090505@redhat.com> <546E2D75.8080900@oracle.com> <546E2F62.4030104@redhat.com> <546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com> Message-ID: <54882CF3.40709@oracle.com> On 28/11/2014 11:41 PM, Volker Simonis wrote: > Hi, > > I think Goetz answered to the remaining questions a few days ago: > > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html > > but for some reason his mail doesn't appear in this mail thread. > > As he wrote, the release store into the card table in graphKit.cpp > isn't needed and we've just removed in in our internal version a few > weeks ago as well. Has anyone from hotspot team confirmed that analysis? I haven't seen anything to that effect and I'm wary of making this kind of change to shared code. Thanks, David > The first one in memnode.hpp is indeed only needed on IA64 so your > solution with AARCH64_ONLY is OK for us. > > Regards, > Volker > > On Fri, Nov 21, 2014 at 7:06 PM, Vladimir Kozlov > wrote: >> On 11/21/14 9:33 AM, Andrew Haley wrote: >>> >>> On 11/20/2014 06:13 PM, Andrew Haley wrote: >>>> >>>> On 11/20/2014 06:05 PM, Vladimir Kozlov wrote: >>>>> >>>>> I based the name on your comment: >>>>> >>>>> + // AArch64 uses store release (which does everything we need to keep >>>>> + // the machine in order) but we still need a compiler barrier here. >>>> >>>> >>>> Ah. Okay, I'll have to think of a good name for it, then. >>>> >>>>> You can name it as you like. Our main suggestion is to use such Boolean >>>>> constant and normal if() statements instead of ifdef AARCH64 and >>>>> AARCH64_ONLY/NOT_AARCH64 macros in C2 code (src/share/vm/opto/* files). >>>>> >>>>> We already do similar things for PPC64 port which sets >>>>> support_IRIW_for_* constant. >>>> >>>> >>>> Okay, >>> >>> >>> I've done something similar but more useful. I've added an >>> experimental flag: UseBarriersForVolatile. This defaults to true for >>> all targets, but we can override it in the back end. That gives me >>> the chance to do some benchmarking on various AArch64 targets to see >>> which ones benefit from the new load acquire/store release >>> instructions. >> >> >> Okay. >> >>> >>> I have kept AARCH64_ONLY for two hunks: >>> >>> --- old/src/share/vm/opto/memnode.hpp 2014-11-21 12:09:22.766963837 >>> -0500 >>> +++ new/src/share/vm/opto/memnode.hpp 2014-11-21 12:09:22.546983320 >>> -0500 >>> @@ -503,6 +503,10 @@ >>> // Conservatively release stores of object references in order to >>> // ensure visibility of object initialization. >>> static inline MemOrd release_if_reference(const BasicType t) { >>> + // AArch64 doesn't need a release store here because object >>> + // initialization contains the necessary barriers. >>> + AARCH64_ONLY(return unordered); >>> + >>> const MemOrd mo = (t == T_ARRAY || >>> t == T_ADDRESS || // Might be the address of an >>> object reference (`boxing'). >>> t == T_OBJECT) ? release : unordered; >> >> >> This could be needed for ppc64 too, not only for IA64. >> >>> >>> --- old/src/share/vm/opto/graphKit.cpp 2014-11-21 12:09:20.017207376 >>> -0500 >>> +++ new/src/share/vm/opto/graphKit.cpp 2014-11-21 12:09:19.787227745 >>> -0500 >>> @@ -3813,7 +3813,8 @@ >>> >>> // Smash zero into card >>> if( !UseConcMarkSweepGC ) { >>> - __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release); >>> + __ store(__ ctrl(), card_adr, zero, bt, adr_type, >>> + NOT_AARCH64(MemNode::release) >>> AARCH64_ONLY(MemNode::unordered)); >>> } else { >>> // Specialized path for CM store barrier >>> __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, >>> adr_type); >> >> >> Looks like PPC64 needs that. In ppc.ad: >> >> // Use release_store for card-marking to ensure that previous >> // oop-stores are visible before the card-mark change. >> enc_class enc_cms_card_mark(memory mem, iRegLdst releaseFieldAddr) %{ >> >>> >>> The first hunk is only required by IA64 as far as I am aware, but I >>> am nervous about making it IA64_ONLY. The second hunk is a release >>> node which is not as far as I am aware required by any target, and >>> should simply be removed. >>> >>> This isn't a RFA because it's not tested yet, but what do you think? >> >> >> Since it affects ppc64 and ia64 we need to ask Goetz and Co. >> I would suggest to put both these places under platform specific flags/bool >> constant. >> >> Thanks, >> Vladimir >> >>> >>> Andrew. >>> >> From david.holmes at oracle.com Wed Dec 10 12:24:03 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Dec 2014 22:24:03 +1000 Subject: AARCH64: 8064611: Changes to HotSpot shared code In-Reply-To: <5488379E.9010200@redhat.com> References: <54625D3D.4000007@redhat.com> <4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap> <54632ABA.5000706@redhat.com> <4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap> <54638FA0.8040204@redhat.com> <546572B8.9080005@oracle.com> <546A1EF5.6060607@redhat.com> <546A60C7.1070408@oracle.com> <546BF7F3.5020507@oracle.com> <546C0881.8050905@oracle.com> <546C1264.6090308@oracle.com> <546DF9D8.3090505@redhat.com> <546E2D75.8080900@oracle.com> <546E2F62.4030104@redhat.com> <546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com> <54882CF3.40709@oracle.com> <5488379E.9010200@redhat.com> Message-ID: <54883B63.9040806@oracle.com> On 10/12/2014 10:07 PM, Andrew Haley wrote: > On 12/10/2014 11:22 AM, David Holmes wrote: >> On 28/11/2014 11:41 PM, Volker Simonis wrote: >>> Hi, >>> >>> I think Goetz answered to the remaining questions a few days ago: >>> >>> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html >>> >>> but for some reason his mail doesn't appear in this mail thread. >>> >>> As he wrote, the release store into the card table in graphKit.cpp >>> isn't needed and we've just removed in in our internal version a few >>> weeks ago as well. >> >> Has anyone from hotspot team confirmed that analysis? I haven't seen >> anything to that effect and I'm wary of making this kind of change to >> shared code. > > The change comes from Goetz; no-one from the HotSpot team knew why it > was there, so they said "ask Goetz", and he said it was a mistake. Got it - PPC64 added it, but it wasn't actually needed. Thanks, David > And besides that, if this releasing store was really needed there > would have to be MemBars for the ports which don't have store release > instructions, but there are none. > > I am, of course, perfectly happy to leave it as ifndef(AARCH64), but > this has been rejected. > > Andrew. > > From goetz.lindenmaier at sap.com Wed Dec 10 13:09:06 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 10 Dec 2014 13:09:06 +0000 Subject: AARCH64: 8064611: Changes to HotSpot shared code In-Reply-To: <5488379E.9010200@redhat.com> References: <54625D3D.4000007@redhat.com> <4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap> <54632ABA.5000706@redhat.com> <4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap> <54638FA0.8040204@redhat.com> <546572B8.9080005@oracle.com> <546A1EF5.6060607@redhat.com> <546A60C7.1070408@oracle.com> <546BF7F3.5020507@oracle.com> <546C0881.8050905@oracle.com> <546C1264.6090308@oracle.com> <546DF9D8.3090505@redhat.com> <546E2D75.8080900@oracle.com> <546E2F62.4030104@redhat.com> <546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com> <54882CF3.40709@oracle.com> <5488379E.9010200@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF3DE1F@DEWDFEMB12A.global.corp.sap> Hi, yes, we verified that this release is not needed. And it was introduced by us. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Mittwoch, 10. Dezember 2014 13:08 To: David Holmes; Volker Simonis; Vladimir Kozlov Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Subject: Re: AARCH64: 8064611: Changes to HotSpot shared code On 12/10/2014 11:22 AM, David Holmes wrote: > On 28/11/2014 11:41 PM, Volker Simonis wrote: >> Hi, >> >> I think Goetz answered to the remaining questions a few days ago: >> >> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html >> >> but for some reason his mail doesn't appear in this mail thread. >> >> As he wrote, the release store into the card table in graphKit.cpp >> isn't needed and we've just removed in in our internal version a few >> weeks ago as well. > > Has anyone from hotspot team confirmed that analysis? I haven't seen > anything to that effect and I'm wary of making this kind of change to > shared code. The change comes from Goetz; no-one from the HotSpot team knew why it was there, so they said "ask Goetz", and he said it was a mistake. And besides that, if this releasing store was really needed there would have to be MemBars for the ports which don't have store release instructions, but there are none. I am, of course, perfectly happy to leave it as ifndef(AARCH64), but this has been rejected. Andrew. From dmitry.samersoff at oracle.com Thu Dec 11 16:44:01 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Dec 2014 19:44:01 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: <5489C9D1.6030508@oracle.com> Volker, Below is fist part of review - shared files. * agent/make/Makefile - no comments * agent/src/os/linux/LinuxDebuggerLocal.c - no comments * agent/src/os/linux/symtab.c: 438: - What is the magic of symbols that starts with '.' ? - As far as I understand you are getting indirect value from opd section. Could you reformat it a bit to have it better readable? Something like: uintptr_t sym_value; ... symvalue = syms->st_value #ifdef ppc64 // Some comments here // ppc specific code here sym_value = #endif symtab->symbols[j].offset = sym_value - baseaddr; 454: I appreciate detailed comments here. if (false) can cause unreachable code warning, and unused variable warning so it might be better to add #ifdef ppc64 on caller site at ll. 516 and leave here only a comment. But if you decide to guard against try_debuginfo please replace if (false) to goto quit * agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java 38: return (endian.equals("big")); is enough * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments * make/linux/makefiles/sa.make - no comments * make/sa.files - no comments * src/share/vm/runtime/vmStructs.cpp - no comments -Dmitry On 2014-12-09 21:10, Volker Simonis wrote: > Hi, > > can somebody from the serviceability team please review this webrev? > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > The shared changes are really all trivial. > > Thanks, > Volker > > > On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >> Hi Sasha, >> >> thanks for looking at this change. >> I'll incorporate your suggestions into the final version. >> I'm just waiting for one more review before preparing a new webrev. >> >> Regards, >> Volker >> >> >> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>> You are correct, but there no need to have this code for LE at all. >>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>> along with the "#if defined(ppc64)". >>>> >>>> BTW, a bit on nitpicking in the same file: >>>> + String endian = System.getProperty("sun.cpu.endian"); >>>> + if (endian.equals("big")) >>>> + return true; >>>> + else >>>> + return false; >>>> can be rewirtten as >>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>> Right. A silly piece of coding there. :-/ >>> >>> -Maynard >>>> >>>> >>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>> The changes for agent/src/os/linux/symtab.c >>>>>> b/agent/src/os/linux/symtab.c in >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>> Linux/PPC64 little-endian: >>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>> brackets in it should >>>>>> read >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> instead of just >>>>>> #if defined(ppc64) >>>>> Hi, Alexander, >>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>> place where I think there may be a problem is at line 455: >>>>> >>>>> -------------------------- >>>>> #if defined(ppc64) >>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>> // with the above algorithm impossible (we would need the have both, the >>>>> // .opd section from the library and the symbol table from the debuginfo >>>>> // file which doesn't match with the current workflow.) >>>>> if (false) { >>>>> #else >>>>> // Look for a separate debuginfo file. >>>>> if (try_debuginfo) { >>>>> #endif >>>>> -------------------------- >>>>> >>>>> Here I think we should do as you suggest: >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> >>>>> -Maynard >>>>>> >>>>>> Sorry for the late notice. >>>>>> Sasha >>>>>> >>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>> change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>> >>>>>>> I have already reviewed and tested the change and from my side >>>>>>> everything looks fine. >>>>>>> >>>>>>> The change touches quite some shared code but all of these changes are >>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>> Java). >>>>>>> >>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>> hotspot repository once the review is completed. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>> >>>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Dec 15 14:32:10 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 15 Dec 2014 17:32:10 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> Message-ID: <548EF0EA.6010200@oracle.com> Volker, This is part two of review. Code looks good for me, only minor nits. * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: 41 missed space around = 51 extra space between pc * agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java 47, 48 extra space before = * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java 34 extra space before id 42 extra space before = , it might be better to create a constant for size of integer. * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java -no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java 43 missed space before ? it might be be better to reformat this line to usual if and add comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java - no comments * agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java 57, 58 extra space before = 63 and below extra space after public 108 unaligned comments * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java 49 Formatting in PPC64Frame.java looks much better for me. 40 private static final boolean DEBUG; 41 static { 42 DEBUG = ... 43 } 60, 61 extra space before = 147 missed {} after if (DEBUG) * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java 49 - 61, please fix extra and missed spaces 64,67 - extra spaces after static 81 missed space after (int) 115,137 - I would prefer to always use {} after if 212 - multiple missed space before '?' 271 extra space before return * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java - no comments * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java - no comments -Dmitry On 2014-12-09 21:10, Volker Simonis wrote: > Hi, > > can somebody from the serviceability team please review this webrev? > > http://cr.openjdk.java.net/~simonis/webrevs/8049716 > https://bugs.openjdk.java.net/browse/JDK-8049716 > > The shared changes are really all trivial. > > Thanks, > Volker > > > On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >> Hi Sasha, >> >> thanks for looking at this change. >> I'll incorporate your suggestions into the final version. >> I'm just waiting for one more review before preparing a new webrev. >> >> Regards, >> Volker >> >> >> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>> You are correct, but there no need to have this code for LE at all. >>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>> along with the "#if defined(ppc64)". >>>> >>>> BTW, a bit on nitpicking in the same file: >>>> + String endian = System.getProperty("sun.cpu.endian"); >>>> + if (endian.equals("big")) >>>> + return true; >>>> + else >>>> + return false; >>>> can be rewirtten as >>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>> Right. A silly piece of coding there. :-/ >>> >>> -Maynard >>>> >>>> >>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>> The changes for agent/src/os/linux/symtab.c >>>>>> b/agent/src/os/linux/symtab.c in >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>> Linux/PPC64 little-endian: >>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>> brackets in it should >>>>>> read >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> instead of just >>>>>> #if defined(ppc64) >>>>> Hi, Alexander, >>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>> place where I think there may be a problem is at line 455: >>>>> >>>>> -------------------------- >>>>> #if defined(ppc64) >>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>> // with the above algorithm impossible (we would need the have both, the >>>>> // .opd section from the library and the symbol table from the debuginfo >>>>> // file which doesn't match with the current workflow.) >>>>> if (false) { >>>>> #else >>>>> // Look for a separate debuginfo file. >>>>> if (try_debuginfo) { >>>>> #endif >>>>> -------------------------- >>>>> >>>>> Here I think we should do as you suggest: >>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>> >>>>> -Maynard >>>>>> >>>>>> Sorry for the late notice. >>>>>> Sasha >>>>>> >>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>> change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>> >>>>>>> I have already reviewed and tested the change and from my side >>>>>>> everything looks fine. >>>>>>> >>>>>>> The change touches quite some shared code but all of these changes are >>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>> Java). >>>>>>> >>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>> hotspot repository once the review is completed. >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>> >>>>> >>>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From maynardj at us.ibm.com Tue Dec 16 16:47:59 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Tue, 16 Dec 2014 10:47:59 -0600 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <548EF0EA.6010200@oracle.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> Message-ID: <5490623F.1020604@us.ibm.com> On 12/15/2014 08:32 AM, Dmitry Samersoff wrote: > Volker, > > This is part two of review. Code looks good for me, only minor nits. Thanks for the review, Dmitry. *Volker*, will you be making the suggested changes (from all review comments) to the patch set or do you want me to do it? Actually, I am retiring from IBM and, as of Friday, will no longer have access to a ppc64 machine or to my IBM email account. So my colleague, Tiago Daitx (on cc) will take over for me any responsibilities left in pushing this patch set upstream. Thanks again for all the help. -Maynard > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: > > 41 missed space around = > 51 extra space between pc > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java > > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java > > 47, 48 extra space before = > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java > > 34 extra space before id > 42 extra space before = , > it might be better to create a constant for size of integer. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java > > -no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java > > 43 missed space before ? > it might be be better to reformat this line to usual if and add comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java > > > 57, 58 extra space before = > > 63 and below extra space after public > > 108 unaligned comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java > > 49 Formatting in PPC64Frame.java looks much better for me. > > 40 private static final boolean DEBUG; > 41 static { > 42 DEBUG = ... > 43 } > > > 60, 61 extra space before = > > 147 missed {} after if (DEBUG) > > * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java > > 49 - 61, please fix extra and missed spaces > > 64,67 - extra spaces after static > 81 missed space after (int) > > 115,137 - I would prefer to always use {} after if > > 212 - multiple missed space before '?' > > 271 extra space before return > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java > > - no comments > > -Dmitry > > > On 2014-12-09 21:10, Volker Simonis wrote: >> Hi, >> >> can somebody from the serviceability team please review this webrev? >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >> https://bugs.openjdk.java.net/browse/JDK-8049716 >> >> The shared changes are really all trivial. >> >> Thanks, >> Volker >> >> >> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>> Hi Sasha, >>> >>> thanks for looking at this change. >>> I'll incorporate your suggestions into the final version. >>> I'm just waiting for one more review before preparing a new webrev. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>> You are correct, but there no need to have this code for LE at all. >>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>> along with the "#if defined(ppc64)". >>>>> >>>>> BTW, a bit on nitpicking in the same file: >>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>> + if (endian.equals("big")) >>>>> + return true; >>>>> + else >>>>> + return false; >>>>> can be rewirtten as >>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>> Right. A silly piece of coding there. :-/ >>>> >>>> -Maynard >>>>> >>>>> >>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>> Linux/PPC64 little-endian: >>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>> brackets in it should >>>>>>> read >>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> instead of just >>>>>>> #if defined(ppc64) >>>>>> Hi, Alexander, >>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>> place where I think there may be a problem is at line 455: >>>>>> >>>>>> -------------------------- >>>>>> #if defined(ppc64) >>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>> // file which doesn't match with the current workflow.) >>>>>> if (false) { >>>>>> #else >>>>>> // Look for a separate debuginfo file. >>>>>> if (try_debuginfo) { >>>>>> #endif >>>>>> -------------------------- >>>>>> >>>>>> Here I think we should do as you suggest: >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>> Sorry for the late notice. >>>>>>> Sasha >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>> change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>> >>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>> everything looks fine. >>>>>>>> >>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>> Java). >>>>>>>> >>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>> hotspot repository once the review is completed. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>> >>>>>> >>>>> >>>> > > From volker.simonis at gmail.com Wed Dec 17 17:37:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 17 Dec 2014 18:37:13 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <548EF0EA.6010200@oracle.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> Message-ID: Hi Dmitry, once again, thanks for your detailed review. You can find the new version of the webrev under: http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ I've rebased it to the latest jdk9/hs-rt repository today. I hope I adressed all your concerns. Please find my additional comments inline below: And I still need a sponsor for pushing this reviewed change. Any volunteers:) Thank you and best regards, Volker > Below is fist part of review - shared files. > > > * agent/make/Makefile - no comments > > * agent/src/os/linux/LinuxDebuggerLocal.c - no comments > > * agent/src/os/linux/symtab.c: > > 438: > - What is the magic of symbols that starts with '.' ? > - As far as I understand you are getting indirect value from opd section. > There's already a very detailed descrition of the whole story in "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a reference to that file in the comment now. > Could you reformat it a bit to have it better readable? > > Something like: > > uintptr_t sym_value; > ... > symvalue = syms->st_value > > #ifdef ppc64 > // Some comments here > // ppc specific code here > sym_value = > #endif > > symtab->symbols[j].offset = sym_value - baseaddr; > Good point. Done as suggested by you. > > 454: > > I appreciate detailed comments here. > > if (false) can cause unreachable code warning, and unused variable > warning so it might be better to add #ifdef ppc64 on caller > site at ll. 516 and leave here only a comment. > > But if you decide to guard against try_debuginfo please replace > > if (false) > > to > > goto quit > I think there's already a comment in place. The problem is that the debuginfo file only has an empty .opd section. So if we would use the debuginfo file for symbol resolution we would still need the .opd section from the regular library. This doesn't fit in the current function work flow which only uses ELF data from a single file and I didn?t wanted to change that. But your suggestion of using 'goto quit' is good and I've used that version. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java > > 38: return (endian.equals("big")); > > is enough > I've used the even shorter version proposed by Alexander Smundak: return "big".equals(System.getProperty("sun.cpu.endian")) > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java > - no comments > > * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments > > * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments > > * make/linux/makefiles/sa.make - no comments > > * make/sa.files - no comments > > * src/share/vm/runtime/vmStructs.cpp > - no comments > > This is part two of review. Code looks good for me, only minor nits. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: > > 41 missed space around = > 51 extra space between pc > Done. > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java > > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java > > 47, 48 extra space before = > Done. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java > > 34 extra space before id > 42 extra space before = , Done. > it might be better to create a constant for size of integer. > I agree, but this code was just copied from the corresponding AMD64 version and as far as I can see all the other architectures do it the same way so I didn't change it. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java > > - no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java > > -no comments > > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java > > 43 missed space before ? > it might be be better to reformat this line to usual if and add comments > The same here - this is copied code. But I've adjusted it to at least match with the other platforms. > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java > > > 57, 58 extra space before = > > 63 and below extra space after public > > 108 unaligned comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java > > 49 Formatting in PPC64Frame.java looks much better for me. > > 40 private static final boolean DEBUG; > 41 static { > 42 DEBUG = ... > 43 } > > > 60, 61 extra space before = > > 147 missed {} after if (DEBUG) > Done. > * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java > > 49 - 61, please fix extra and missed spaces > > 64,67 - extra spaces after static > 81 missed space after (int) > > 115,137 - I would prefer to always use {} after if > > 212 - multiple missed space before '?' > > 271 extra space before return > Done. > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java > > - no comments > > * > agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java > > - no comments > > -Dmitry > > > On 2014-12-09 21:10, Volker Simonis wrote: >> Hi, >> >> can somebody from the serviceability team please review this webrev? >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >> https://bugs.openjdk.java.net/browse/JDK-8049716 >> >> The shared changes are really all trivial. >> >> Thanks, >> Volker >> >> >> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>> Hi Sasha, >>> >>> thanks for looking at this change. >>> I'll incorporate your suggestions into the final version. >>> I'm just waiting for one more review before preparing a new webrev. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>> You are correct, but there no need to have this code for LE at all. >>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>> along with the "#if defined(ppc64)". >>>>> >>>>> BTW, a bit on nitpicking in the same file: >>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>> + if (endian.equals("big")) >>>>> + return true; >>>>> + else >>>>> + return false; >>>>> can be rewirtten as >>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>> Right. A silly piece of coding there. :-/ >>>> >>>> -Maynard >>>>> >>>>> >>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>> Linux/PPC64 little-endian: >>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>> brackets in it should >>>>>>> read >>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> instead of just >>>>>>> #if defined(ppc64) >>>>>> Hi, Alexander, >>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>> place where I think there may be a problem is at line 455: >>>>>> >>>>>> -------------------------- >>>>>> #if defined(ppc64) >>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>> // file which doesn't match with the current workflow.) >>>>>> if (false) { >>>>>> #else >>>>>> // Look for a separate debuginfo file. >>>>>> if (try_debuginfo) { >>>>>> #endif >>>>>> -------------------------- >>>>>> >>>>>> Here I think we should do as you suggest: >>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>> Sorry for the late notice. >>>>>>> Sasha >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>> change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>> >>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>> everything looks fine. >>>>>>>> >>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>> Java). >>>>>>>> >>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>> hotspot repository once the review is completed. >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> Volker >>>>>>> >>>>>> >>>>> >>>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Dec 17 18:06:20 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 17 Dec 2014 21:06:20 +0300 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> Message-ID: <5491C61C.1060609@oracle.com> Volker, The changes looks good for me and I'll sponsor the push. But please check, whether you need one more reviewer or not. -Dmitry On 2014-12-17 20:37, Volker Simonis wrote: > Hi Dmitry, > > once again, thanks for your detailed review. You can find the new > version of the webrev under: > > http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ > > I've rebased it to the latest jdk9/hs-rt repository today. > > I hope I adressed all your concerns. Please find my additional > comments inline below: > > And I still need a sponsor for pushing this reviewed change. Any volunteers:) > > Thank you and best regards, > Volker > >> Below is fist part of review - shared files. >> >> >> * agent/make/Makefile - no comments >> >> * agent/src/os/linux/LinuxDebuggerLocal.c - no comments >> >> * agent/src/os/linux/symtab.c: >> >> 438: >> - What is the magic of symbols that starts with '.' ? >> - As far as I understand you are getting indirect value from opd section. >> > > There's already a very detailed descrition of the whole story in > "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a > reference to that file in the comment now. > >> Could you reformat it a bit to have it better readable? >> >> Something like: >> >> uintptr_t sym_value; >> ... >> symvalue = syms->st_value >> >> #ifdef ppc64 >> // Some comments here >> // ppc specific code here >> sym_value = >> #endif >> >> symtab->symbols[j].offset = sym_value - baseaddr; >> > > Good point. Done as suggested by you. > >> >> 454: >> >> I appreciate detailed comments here. >> >> if (false) can cause unreachable code warning, and unused variable >> warning so it might be better to add #ifdef ppc64 on caller >> site at ll. 516 and leave here only a comment. >> >> But if you decide to guard against try_debuginfo please replace >> >> if (false) >> >> to >> >> goto quit >> > > I think there's already a comment in place. The problem is that the > debuginfo file only has an empty .opd section. So if we would use the > debuginfo file for symbol resolution we would still need the .opd > section from the regular library. This doesn't fit in the current > function work flow which only uses ELF data from a single file and I > didn?t wanted to change that. > > But your suggestion of using 'goto quit' is good and I've used that version. > >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java >> >> 38: return (endian.equals("big")); >> >> is enough >> > > I've used the even shorter version proposed by Alexander Smundak: > > return "big".equals(System.getProperty("sun.cpu.endian")) > >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java >> - no comments >> >> * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments >> >> * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments >> >> * make/linux/makefiles/sa.make - no comments >> >> * make/sa.files - no comments >> >> * src/share/vm/runtime/vmStructs.cpp >> - no comments >> > >> This is part two of review. Code looks good for me, only minor nits. >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: >> >> 41 missed space around = >> 51 extra space between pc >> > > Done. > >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java >> >> >> - no comments >> >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java >> >> 47, 48 extra space before = >> > > Done. > >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java >> >> 34 extra space before id >> 42 extra space before = , > > Done. > >> it might be better to create a constant for size of integer. >> > > I agree, but this code was just copied from the corresponding AMD64 > version and as far as I can see all the other architectures do it the > same way so I didn't change it. > >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java >> >> - no comments >> >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java >> >> -no comments >> >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java >> >> 43 missed space before ? >> it might be be better to reformat this line to usual if and add comments >> > > The same here - this is copied code. But I've adjusted it to at least > match with the other platforms. > >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java >> >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java >> >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java >> >> >> 57, 58 extra space before = >> >> 63 and below extra space after public >> >> 108 unaligned comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java >> >> 49 Formatting in PPC64Frame.java looks much better for me. >> >> 40 private static final boolean DEBUG; >> 41 static { >> 42 DEBUG = ... >> 43 } >> >> >> 60, 61 extra space before = >> >> 147 missed {} after if (DEBUG) >> > > Done. > >> * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java >> >> 49 - 61, please fix extra and missed spaces >> >> 64,67 - extra spaces after static >> 81 missed space after (int) >> >> 115,137 - I would prefer to always use {} after if >> >> 212 - multiple missed space before '?' >> >> 271 extra space before return >> > > Done. > >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java >> >> - no comments >> >> * >> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java >> >> - no comments >> >> -Dmitry >> >> >> On 2014-12-09 21:10, Volker Simonis wrote: >>> Hi, >>> >>> can somebody from the serviceability team please review this webrev? >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>> >>> The shared changes are really all trivial. >>> >>> Thanks, >>> Volker >>> >>> >>> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>>> Hi Sasha, >>>> >>>> thanks for looking at this change. >>>> I'll incorporate your suggestions into the final version. >>>> I'm just waiting for one more review before preparing a new webrev. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>>> You are correct, but there no need to have this code for LE at all. >>>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>>> along with the "#if defined(ppc64)". >>>>>> >>>>>> BTW, a bit on nitpicking in the same file: >>>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>>> + if (endian.equals("big")) >>>>>> + return true; >>>>>> + else >>>>>> + return false; >>>>>> can be rewirtten as >>>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>>> Right. A silly piece of coding there. :-/ >>>>> >>>>> -Maynard >>>>>> >>>>>> >>>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>>> Linux/PPC64 little-endian: >>>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>>> brackets in it should >>>>>>>> read >>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>> instead of just >>>>>>>> #if defined(ppc64) >>>>>>> Hi, Alexander, >>>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>>> place where I think there may be a problem is at line 455: >>>>>>> >>>>>>> -------------------------- >>>>>>> #if defined(ppc64) >>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>>> // file which doesn't match with the current workflow.) >>>>>>> if (false) { >>>>>>> #else >>>>>>> // Look for a separate debuginfo file. >>>>>>> if (try_debuginfo) { >>>>>>> #endif >>>>>>> -------------------------- >>>>>>> >>>>>>> Here I think we should do as you suggest: >>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> >>>>>>> -Maynard >>>>>>>> >>>>>>>> Sorry for the late notice. >>>>>>>> Sasha >>>>>>>> >>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>> change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>> >>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>> everything looks fine. >>>>>>>>> >>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>> Java). >>>>>>>>> >>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>> hotspot repository once the review is completed. >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> Volker >>>>>>>> >>>>>>> >>>>>> >>>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Dec 18 09:31:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 18 Dec 2014 10:31:31 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: <5491C61C.1060609@oracle.com> References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> <5491C61C.1060609@oracle.com> Message-ID: Since both Volker and Dmitry have reviewed this, no further reviews are necessary. I took a look at the changes in shared code, anyway, and it looks good. Thanks, /Staffan > On 17 dec 2014, at 19:06, Dmitry Samersoff wrote: > > Volker, > > The changes looks good for me and I'll sponsor the push. > > But please check, whether you need one more reviewer or not. > > -Dmitry > > On 2014-12-17 20:37, Volker Simonis wrote: >> Hi Dmitry, >> >> once again, thanks for your detailed review. You can find the new >> version of the webrev under: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ >> >> I've rebased it to the latest jdk9/hs-rt repository today. >> >> I hope I adressed all your concerns. Please find my additional >> comments inline below: >> >> And I still need a sponsor for pushing this reviewed change. Any volunteers:) >> >> Thank you and best regards, >> Volker >> >>> Below is fist part of review - shared files. >>> >>> >>> * agent/make/Makefile - no comments >>> >>> * agent/src/os/linux/LinuxDebuggerLocal.c - no comments >>> >>> * agent/src/os/linux/symtab.c: >>> >>> 438: >>> - What is the magic of symbols that starts with '.' ? >>> - As far as I understand you are getting indirect value from opd section. >>> >> >> There's already a very detailed descrition of the whole story in >> "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a >> reference to that file in the comment now. >> >>> Could you reformat it a bit to have it better readable? >>> >>> Something like: >>> >>> uintptr_t sym_value; >>> ... >>> symvalue = syms->st_value >>> >>> #ifdef ppc64 >>> // Some comments here >>> // ppc specific code here >>> sym_value = >>> #endif >>> >>> symtab->symbols[j].offset = sym_value - baseaddr; >>> >> >> Good point. Done as suggested by you. >> >>> >>> 454: >>> >>> I appreciate detailed comments here. >>> >>> if (false) can cause unreachable code warning, and unused variable >>> warning so it might be better to add #ifdef ppc64 on caller >>> site at ll. 516 and leave here only a comment. >>> >>> But if you decide to guard against try_debuginfo please replace >>> >>> if (false) >>> >>> to >>> >>> goto quit >>> >> >> I think there's already a comment in place. The problem is that the >> debuginfo file only has an empty .opd section. So if we would use the >> debuginfo file for symbol resolution we would still need the .opd >> section from the regular library. This doesn't fit in the current >> function work flow which only uses ELF data from a single file and I >> didn?t wanted to change that. >> >> But your suggestion of using 'goto quit' is good and I've used that version. >> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java >>> >>> 38: return (endian.equals("big")); >>> >>> is enough >>> >> >> I've used the even shorter version proposed by Alexander Smundak: >> >> return "big".equals(System.getProperty("sun.cpu.endian")) >> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java >>> - no comments >>> >>> * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments >>> >>> * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments >>> >>> * make/linux/makefiles/sa.make - no comments >>> >>> * make/sa.files - no comments >>> >>> * src/share/vm/runtime/vmStructs.cpp >>> - no comments >>> >> >>> This is part two of review. Code looks good for me, only minor nits. >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: >>> >>> 41 missed space around = >>> 51 extra space between pc >>> >> >> Done. >> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java >>> >>> >>> - no comments >>> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java >>> >>> 47, 48 extra space before = >>> >> >> Done. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java >>> >>> 34 extra space before id >>> 42 extra space before = , >> >> Done. >> >>> it might be better to create a constant for size of integer. >>> >> >> I agree, but this code was just copied from the corresponding AMD64 >> version and as far as I can see all the other architectures do it the >> same way so I didn't change it. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java >>> >>> - no comments >>> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java >>> >>> -no comments >>> >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java >>> >>> 43 missed space before ? >>> it might be be better to reformat this line to usual if and add comments >>> >> >> The same here - this is copied code. But I've adjusted it to at least >> match with the other platforms. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java >>> >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java >>> >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java >>> >>> >>> 57, 58 extra space before = >>> >>> 63 and below extra space after public >>> >>> 108 unaligned comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java >>> >>> 49 Formatting in PPC64Frame.java looks much better for me. >>> >>> 40 private static final boolean DEBUG; >>> 41 static { >>> 42 DEBUG = ... >>> 43 } >>> >>> >>> 60, 61 extra space before = >>> >>> 147 missed {} after if (DEBUG) >>> >> >> Done. >> >>> * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java >>> >>> 49 - 61, please fix extra and missed spaces >>> >>> 64,67 - extra spaces after static >>> 81 missed space after (int) >>> >>> 115,137 - I would prefer to always use {} after if >>> >>> 212 - multiple missed space before '?' >>> >>> 271 extra space before return >>> >> >> Done. >> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java >>> >>> - no comments >>> >>> * >>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java >>> >>> - no comments >>> >>> -Dmitry >>> >>> >>> On 2014-12-09 21:10, Volker Simonis wrote: >>>> Hi, >>>> >>>> can somebody from the serviceability team please review this webrev? >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>> >>>> The shared changes are really all trivial. >>>> >>>> Thanks, >>>> Volker >>>> >>>> >>>> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>>>> Hi Sasha, >>>>> >>>>> thanks for looking at this change. >>>>> I'll incorporate your suggestions into the final version. >>>>> I'm just waiting for one more review before preparing a new webrev. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>>>> You are correct, but there no need to have this code for LE at all. >>>>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>>>> along with the "#if defined(ppc64)". >>>>>>> >>>>>>> BTW, a bit on nitpicking in the same file: >>>>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>>>> + if (endian.equals("big")) >>>>>>> + return true; >>>>>>> + else >>>>>>> + return false; >>>>>>> can be rewirtten as >>>>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>>>> Right. A silly piece of coding there. :-/ >>>>>> >>>>>> -Maynard >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>>>> Linux/PPC64 little-endian: >>>>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>>>> brackets in it should >>>>>>>>> read >>>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>>> instead of just >>>>>>>>> #if defined(ppc64) >>>>>>>> Hi, Alexander, >>>>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>>>> place where I think there may be a problem is at line 455: >>>>>>>> >>>>>>>> -------------------------- >>>>>>>> #if defined(ppc64) >>>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>>>> // file which doesn't match with the current workflow.) >>>>>>>> if (false) { >>>>>>>> #else >>>>>>>> // Look for a separate debuginfo file. >>>>>>>> if (try_debuginfo) { >>>>>>>> #endif >>>>>>>> -------------------------- >>>>>>>> >>>>>>>> Here I think we should do as you suggest: >>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>> >>>>>>>> -Maynard >>>>>>>>> >>>>>>>>> Sorry for the late notice. >>>>>>>>> Sasha >>>>>>>>> >>>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>>> change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>>> >>>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>>> everything looks fine. >>>>>>>>>> >>>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>>> Java). >>>>>>>>>> >>>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>>> hotspot repository once the review is completed. >>>>>>>>>> >>>>>>>>>> Thank you and best regards, >>>>>>>>>> Volker >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Thu Dec 18 09:38:38 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Dec 2014 10:38:38 +0100 Subject: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64 In-Reply-To: References: <5480F1AA.4010900@us.ibm.com> <5481BCF2.9050501@us.ibm.com> <548EF0EA.6010200@oracle.com> <5491C61C.1060609@oracle.com> Message-ID: Great Staffan! Thanks a lot, Volker On Thu, Dec 18, 2014 at 10:31 AM, Staffan Larsen wrote: > Since both Volker and Dmitry have reviewed this, no further reviews are necessary. I took a look at the changes in shared code, anyway, and it looks good. > > Thanks, > /Staffan > >> On 17 dec 2014, at 19:06, Dmitry Samersoff wrote: >> >> Volker, >> >> The changes looks good for me and I'll sponsor the push. >> >> But please check, whether you need one more reviewer or not. >> >> -Dmitry >> >> On 2014-12-17 20:37, Volker Simonis wrote: >>> Hi Dmitry, >>> >>> once again, thanks for your detailed review. You can find the new >>> version of the webrev under: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8049716.v2/ >>> >>> I've rebased it to the latest jdk9/hs-rt repository today. >>> >>> I hope I adressed all your concerns. Please find my additional >>> comments inline below: >>> >>> And I still need a sponsor for pushing this reviewed change. Any volunteers:) >>> >>> Thank you and best regards, >>> Volker >>> >>>> Below is fist part of review - shared files. >>>> >>>> >>>> * agent/make/Makefile - no comments >>>> >>>> * agent/src/os/linux/LinuxDebuggerLocal.c - no comments >>>> >>>> * agent/src/os/linux/symtab.c: >>>> >>>> 438: >>>> - What is the magic of symbols that starts with '.' ? >>>> - As far as I understand you are getting indirect value from opd section. >>>> >>> >>> There's already a very detailed descrition of the whole story in >>> "hotspot/src/share/vm/utilities/elfFuncDescTable.hpp" and I've added a >>> reference to that file in the comment now. >>> >>>> Could you reformat it a bit to have it better readable? >>>> >>>> Something like: >>>> >>>> uintptr_t sym_value; >>>> ... >>>> symvalue = syms->st_value >>>> >>>> #ifdef ppc64 >>>> // Some comments here >>>> // ppc specific code here >>>> sym_value = >>>> #endif >>>> >>>> symtab->symbols[j].offset = sym_value - baseaddr; >>>> >>> >>> Good point. Done as suggested by you. >>> >>>> >>>> 454: >>>> >>>> I appreciate detailed comments here. >>>> >>>> if (false) can cause unreachable code warning, and unused variable >>>> warning so it might be better to add #ifdef ppc64 on caller >>>> site at ll. 516 and leave here only a comment. >>>> >>>> But if you decide to guard against try_debuginfo please replace >>>> >>>> if (false) >>>> >>>> to >>>> >>>> goto quit >>>> >>> >>> I think there's already a comment in place. The problem is that the >>> debuginfo file only has an empty .opd section. So if we would use the >>> debuginfo file for symbol resolution we would still need the .opd >>> section from the regular library. This doesn't fit in the current >>> function work flow which only uses ELF data from a single file and I >>> didn?t wanted to change that. >>> >>> But your suggestion of using 'goto quit' is good and I've used that version. >>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionPPC64.java >>>> >>>> 38: return (endian.equals("big")); >>>> >>>> is enough >>>> >>> >>> I've used the even shorter version proposed by Alexander Smundak: >>> >>> return "big".equals(System.getProperty("sun.cpu.endian")) >>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java >>>> - no comments >>>> >>>> * agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java - no comments >>>> >>>> * agent/src/share/classes/sun/jvm/hotspot/runtime/VFrame.java - no comments >>>> >>>> * make/linux/makefiles/sa.make - no comments >>>> >>>> * make/sa.files - no comments >>>> >>>> * src/share/vm/runtime/vmStructs.cpp >>>> - no comments >>>> >>> >>>> This is part two of review. Code looks good for me, only minor nits. >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java: >>>> >>>> 41 missed space around = >>>> 51 extra space between pc >>>> >>> >>> Done. >>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64ThreadContext.java >>>> >>>> >>>> - no comments >>>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/ppc64/PPC64ThreadContext.java >>>> >>>> 47, 48 extra space before = >>>> >>> >>> Done. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64Thread.java >>>> >>>> 34 extra space before id >>>> 42 extra space before = , >>> >>> Done. >>> >>>> it might be better to create a constant for size of integer. >>>> >>> >>> I agree, but this code was just copied from the corresponding AMD64 >>> version and as far as I can see all the other architectures do it the >>> same way so I didn't change it. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadContext.java >>>> >>>> - no comments >>>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ppc64/ProcPPC64ThreadFactory.java >>>> >>>> -no comments >>>> >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64Thread.java >>>> >>>> 43 missed space before ? >>>> it might be be better to reformat this line to usual if and add comments >>>> >>> >>> The same here - this is copied code. But I've adjusted it to at least >>> match with the other platforms. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadContext.java >>>> >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/debugger/remote/ppc64/RemotePPC64ThreadFactory.java >>>> >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ppc64/LinuxPPC64JavaThreadPDAccess.java >>>> >>>> >>>> 57, 58 extra space before = >>>> >>>> 63 and below extra space after public >>>> >>>> 108 unaligned comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64CurrentFrameGuess.java >>>> >>>> 49 Formatting in PPC64Frame.java looks much better for me. >>>> >>>> 40 private static final boolean DEBUG; >>>> 41 static { >>>> 42 DEBUG = ... >>>> 43 } >>>> >>>> >>>> 60, 61 extra space before = >>>> >>>> 147 missed {} after if (DEBUG) >>>> >>> >>> Done. >>> >>>> * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java >>>> >>>> 49 - 61, please fix extra and missed spaces >>>> >>>> 64,67 - extra spaces after static >>>> 81 missed space after (int) >>>> >>>> 115,137 - I would prefer to always use {} after if >>>> >>>> 212 - multiple missed space before '?' >>>> >>>> 271 extra space before return >>>> >>> >>> Done. >>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64JavaCallWrapper.java >>>> >>>> - no comments >>>> >>>> * >>>> agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64RegisterMap.java >>>> >>>> - no comments >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-12-09 21:10, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> can somebody from the serviceability team please review this webrev? >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>> >>>>> The shared changes are really all trivial. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Dec 5, 2014 at 4:01 PM, Volker Simonis wrote: >>>>>> Hi Sasha, >>>>>> >>>>>> thanks for looking at this change. >>>>>> I'll incorporate your suggestions into the final version. >>>>>> I'm just waiting for one more review before preparing a new webrev. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Fri, Dec 5, 2014 at 3:10 PM, Maynard Johnson wrote: >>>>>>> On 12/04/2014 07:50 PM, Alexander Smundak wrote: >>>>>>>> You are correct, but there no need to have this code for LE at all. >>>>>>> Agreed. I'm fine with adding the "&& !defined(ABI_ELFv2)" throughout that file >>>>>>> along with the "#if defined(ppc64)". >>>>>>>> >>>>>>>> BTW, a bit on nitpicking in the same file: >>>>>>>> + String endian = System.getProperty("sun.cpu.endian"); >>>>>>>> + if (endian.equals("big")) >>>>>>>> + return true; >>>>>>>> + else >>>>>>>> + return false; >>>>>>>> can be rewirtten as >>>>>>>> return "big".equals(System.getProperty("sun.cpu.endian")); >>>>>>> Right. A silly piece of coding there. :-/ >>>>>>> >>>>>>> -Maynard >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 4, 2014 at 3:43 PM, Maynard Johnson wrote: >>>>>>>>> On 12/04/2014 01:15 PM, Alexander Smundak wrote: >>>>>>>>>> The changes for agent/src/os/linux/symtab.c >>>>>>>>>> b/agent/src/os/linux/symtab.c in >>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 will break >>>>>>>>>> Linux/PPC64 little-endian: >>>>>>>>>> it uses ABIv2, which dropped function descriptors. So the preprocessor >>>>>>>>>> brackets in it should >>>>>>>>>> read >>>>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>>>> instead of just >>>>>>>>>> #if defined(ppc64) >>>>>>>>> Hi, Alexander, >>>>>>>>> I think this is actually fine everywhere except one place. The 'opd' variable will be >>>>>>>>> set to something other than NULL at line 379 only if running on ppc64 BE. So in >>>>>>>>> the rest of that function, opd is checked for non-null before using it. The only >>>>>>>>> place where I think there may be a problem is at line 455: >>>>>>>>> >>>>>>>>> -------------------------- >>>>>>>>> #if defined(ppc64) >>>>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>>>> // with the above algorithm impossible (we would need the have both, the >>>>>>>>> // .opd section from the library and the symbol table from the debuginfo >>>>>>>>> // file which doesn't match with the current workflow.) >>>>>>>>> if (false) { >>>>>>>>> #else >>>>>>>>> // Look for a separate debuginfo file. >>>>>>>>> if (try_debuginfo) { >>>>>>>>> #endif >>>>>>>>> -------------------------- >>>>>>>>> >>>>>>>>> Here I think we should do as you suggest: >>>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>>> >>>>>>>>> -Maynard >>>>>>>>>> >>>>>>>>>> Sorry for the late notice. >>>>>>>>>> Sasha >>>>>>>>>> >>>>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>>>> change: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>>>> >>>>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>>>> everything looks fine. >>>>>>>>>>> >>>>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>>>> Java). >>>>>>>>>>> >>>>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>>>> hotspot repository once the review is completed. >>>>>>>>>>> >>>>>>>>>>> Thank you and best regards, >>>>>>>>>>> Volker >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > From volker.simonis at gmail.com Fri Dec 19 14:45:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Dec 2014 15:45:27 +0100 Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols at build time and suppress warning 1540-1639 Message-ID: Hi, can somebody please review this tiny, AIX-only build changes: http://cr.openjdk.java.net/~simonis/webrevs/8067923 https://bugs.openjdk.java.net/browse/JDK-8067923 '-bernotok' is the AIX linkers equivalent to Linux ld's '-z defs'. It's better to detect missing symbols already at build time. Also supress the warning "1540-1639 (I) The behavior of long type bit fields has changed from previous releases of this compiler. In 64-bit mode, long type bit fields now default to long, not int." The warning is only informational (i.e. "(I)") but very annoying because it is printed for the bit-fields in "src/share/vm/services/mallocTracker.hpp" which is included in virtually every compilation unit. Thanks, Volker From goetz.lindenmaier at sap.com Fri Dec 19 16:11:36 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 19 Dec 2014 16:11:36 +0000 Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols at build time and suppress warning 1540-1639 In-Reply-To: References: Message-ID: <4295855A5C1DE049A61835A1887419CC2CF43399@DEWDFEMB12A.global.corp.sap> Hi Volker, it's good to fix these two issues, thanks! The patch works nicely. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Freitag, 19. Dezember 2014 15:45 To: HotSpot Open Source Developers; ppc-aix-port-dev at openjdk.java.net Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols at build time and suppress warning 1540-1639 Hi, can somebody please review this tiny, AIX-only build changes: http://cr.openjdk.java.net/~simonis/webrevs/8067923 https://bugs.openjdk.java.net/browse/JDK-8067923 '-bernotok' is the AIX linkers equivalent to Linux ld's '-z defs'. It's better to detect missing symbols already at build time. Also supress the warning "1540-1639 (I) The behavior of long type bit fields has changed from previous releases of this compiler. In 64-bit mode, long type bit fields now default to long, not int." The warning is only informational (i.e. "(I)") but very annoying because it is printed for the bit-fields in "src/share/vm/services/mallocTracker.hpp" which is included in virtually every compilation unit. Thanks, Volker From vladimir.kozlov at oracle.com Fri Dec 19 17:54:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 09:54:58 -0800 Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols at build time and suppress warning 1540-1639 In-Reply-To: References: Message-ID: <54946672.2090109@oracle.com> Looks good. Thanks, Vladimir On 12/19/14 6:45 AM, Volker Simonis wrote: > Hi, > > can somebody please review this tiny, AIX-only build changes: > > http://cr.openjdk.java.net/~simonis/webrevs/8067923 > https://bugs.openjdk.java.net/browse/JDK-8067923 > > '-bernotok' is the AIX linkers equivalent to Linux ld's '-z defs'. > > It's better to detect missing symbols already at build time. > > Also supress the warning "1540-1639 (I) The behavior of long type bit > fields has changed from previous releases of this compiler. In 64-bit > mode, long type bit fields now default to long, not int." > > The warning is only informational (i.e. "(I)") but very annoying > because it is printed for the bit-fields in > "src/share/vm/services/mallocTracker.hpp" which is included in > virtually every compilation unit. > > Thanks, > Volker > From castelnj at br.ibm.com Wed Dec 31 12:29:46 2014 From: castelnj at br.ibm.com (castelnj at br.ibm.com) Date: Wed, 31 Dec 2014 10:29:46 -0200 Subject: Test Message-ID: Test, please delete this message Regards Nivaldo Jose Castelan Junior IT Specialist GDC Brazil, Application Hosting Services Phone: 55-19-2132-3015 E-mail: castelnj at br.ibm.com Chat: castelnj at br.ibm.com Find me on: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3766 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 518 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 15585 bytes Desc: not available URL: