From jcbeyler at google.com Sat Sep 1 00:12:25 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 31 Aug 2018 17:12:25 -0700 Subject: RFR (M) 8210182: Remove macros for C compilation from vmTestBase but non jvmti In-Reply-To: <9adcb1cb-824d-c9a7-238b-af59e9f0e27b@oracle.com> References: <7d0908e3-f8d5-c6a4-7d04-c45d17f8ad55@oracle.com> <270cd0af-fb4f-e2f2-472e-c449ba4d3ba5@oracle.com> <9adcb1cb-824d-c9a7-238b-af59e9f0e27b@oracle.com> Message-ID: Hi all, Thanks for the reviews, I'll fix the issue that Serguei pointed out and I ran the vmTestBase and all tests pass now with the fix that Alex pointed out. Thanks again, Jc On Fri, Aug 31, 2018 at 4:02 PM Chris Plummer wrote: > Hi JC, > > Other than what Serguei pointed out, it looks good. > > thanks, > > Chris > > On 8/30/18 11:31 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > The fix looks great as it looks much more simple now! > > One minor suggestion about this file update: > > > http://cr.openjdk.java.net/%7Ejcbeyler/8210182/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/share/jpda/libNativeMethodsTestThread.cpp.udiff.html > > An example: > > + env->CallVoidMethod(thisObject, env->GetMethodID(klass, "log", "(Ljava/lang/String;)V"), + message); > > I'd suggest either to place one call at one line, or place each argument > on a different line like this: > > + env->CallVoidMethod(thisObject, > + env->GetMethodID(klass, "log", "(Ljava/lang/String;)V"), + message); > > There are several similar cases in this file. > > No need in another webrev if you fix this. > > > Thanks, > Serguei > > > On 8/30/18 12:03, JC Beyler wrote: > > Hi Alex, > > I've fixed those cases and found an extra one. I'll revise my scripts for > the next folder so these no longer happen (bad regexp that eagerly finds a > ')'. > > I had launched in parallel a test for vmTestBase, it finished with a few > failures that might be linked to this so I have relaunched the whole > vmTestBase and will post the results here. > > The new webrev with the fixes is here: > http://cr.openjdk.java.net/~jcbeyler/8210182/webrev.02/ > > Thanks again for the review, > Jc > > On Thu, Aug 30, 2018 at 10:48 AM Alex Menkov > wrote: > >> Hi Jc, >> >> It looks much better now. >> BTW did you run all the tests? >> >> test/hotspot/jtreg/vmTestbase/nsk/share/jni/JNIreferences.cpp >> "(V" should be "()V": >> >> // notify another thread that JNI local reference has been >> created >> - JNI_ENV_PTR(env)->CallVoidMethod(JNI_ENV_ARG_3(env, >> createWicket, JNI_ENV_PTR(env)->GetMethodID(JNI_ENV_ARG_4(env, klass, >> "unlock", "()V")))); >> + env->CallVoidMethod(createWicket, env->GetMethodID(klass, >> "unlock", "(V")); >> >> // wait till JNI local reference can be released (it will >> heppen then we will leave the method) >> - JNI_ENV_PTR(env)->CallVoidMethod(JNI_ENV_ARG_3(env, >> deleteWicket, JNI_ENV_PTR(env)->GetMethodID(JNI_ENV_ARG_4(env, klass, >> "waitFor", "()V")))); >> + env->CallVoidMethod(deleteWicket, env->GetMethodID(klass, >> "waitFor", "(V")); >> } >> >> --alex >> >> On 08/29/2018 22:01, JC Beyler wrote: >> > Hi all, >> > >> > A follow-up to Igor's work on getting tests in C++, I am working on >> > simplifying the macros in the tests from the vmTestBase. The full >> change >> > being a bit too large, I'm cutting it up in pieces to be easier to >> > review and integrate. >> > >> > Here is the first part, it changes all vmTestbase tests outside the >> > vmTestbase/jvmti subfolder: >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210182/webrev.01/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210182 >> > >> > Thanks! >> > Jc >> > > > -- > > Thanks, > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Sep 3 07:27:50 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Sep 2018 08:27:50 +0100 Subject: 8210087: Classes in jdk.unsupported not accessible from jconsole plugin Message-ID: JDK-8210087 [1] is an issue with the launcher generated for jconsole. The launcher needs to be compiled with --add-modules ALL-DEFAULT so that plugins compiled (and run) in an unnamed module can make use of exported APIs in modules that aren't resolved by jdk.jconsole. The change is trivial: diff -r cdef4df6b0e7 make/launcher/Launcher-jdk.jconsole.gmk --- a/make/launcher/Launcher-jdk.jconsole.gmk??? Fri Aug 31 10:22:04 2018 -0400 +++ b/make/launcher/Launcher-jdk.jconsole.gmk??? Mon Sep 03 07:56:56 2018 +0100 @@ -28,6 +28,7 @@ ?$(eval $(call SetupBuildLauncher, jconsole, \ ???? MAIN_CLASS := sun.tools.jconsole.JConsole, \ ???? JAVA_ARGS := --add-opens java.base/java.io=jdk.jconsole \ +???????????????? --add-modules ALL-DEFAULT \ ???? ??? ?-Djconsole.showOutputViewer, \ ???? CFLAGS_windows := -DJAVAW, \ ???? LIBS_windows := user32.lib, \ jconsole is headful so I'm not planning to include a test at this time. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8210087 From gary.adams at oracle.com Tue Sep 4 12:22:10 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 04 Sep 2018 08:22:10 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE Message-ID: <5B8E78F1.3080205@oracle.com> Here's a quick fix to avoid the NPE using a getThreadGroup() which could be null if the thread has terminated. Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java b/test/jdk/com/sun/jdi/DebuggerThreadTest.java --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java @@ -77,7 +77,8 @@ int gotThreads = tg.enumerate(list, true); for (int i = 0; i < Math.min(gotThreads, list.length); i++){ Thread t = list[i]; - String groupName = t.getThreadGroup().getName(); + ThreadGroup tga = t.getThreadGroup(); + String groupName = (tga == null ? "": tga.getName()); System.out.println("Thread [" + i + "] group = '" + groupName + -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Sep 4 15:50:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 08:50:31 -0700 Subject: 8210087: Classes in jdk.unsupported not accessible from jconsole plugin In-Reply-To: References: Message-ID: <80ef71c6-7bb5-67c2-087a-025269c43443@oracle.com> Looks good. /Erik On 2018-09-03 00:27, Alan Bateman wrote: > > JDK-8210087 [1] is an issue with the launcher generated for jconsole. > The launcher needs to be compiled with --add-modules ALL-DEFAULT so > that plugins compiled (and run) in an unnamed module can make use of > exported APIs in modules that aren't resolved by jdk.jconsole. The > change is trivial: > > diff -r cdef4df6b0e7 make/launcher/Launcher-jdk.jconsole.gmk > --- a/make/launcher/Launcher-jdk.jconsole.gmk??? Fri Aug 31 10:22:04 > 2018 -0400 > +++ b/make/launcher/Launcher-jdk.jconsole.gmk??? Mon Sep 03 07:56:56 > 2018 +0100 > @@ -28,6 +28,7 @@ > ?$(eval $(call SetupBuildLauncher, jconsole, \ > ???? MAIN_CLASS := sun.tools.jconsole.JConsole, \ > ???? JAVA_ARGS := --add-opens java.base/java.io=jdk.jconsole \ > +???????????????? --add-modules ALL-DEFAULT \ > ???? ??? ?-Djconsole.showOutputViewer, \ > ???? CFLAGS_windows := -DJAVAW, \ > ???? LIBS_windows := user32.lib, \ > > jconsole is headful so I'm not planning to include a test at this time. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8210087 From chris.plummer at oracle.com Tue Sep 4 17:51:10 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 4 Sep 2018 10:51:10 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B8E78F1.3080205@oracle.com> References: <5B8E78F1.3080205@oracle.com> Message-ID: Hi Gary, Why has the thread exited if the debuggee is still running? Chris On 9/4/18 5:22 AM, Gary Adams wrote: > Here's a quick fix to avoid the NPE using a getThreadGroup() which > could be null > if the thread has terminated. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 > > diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java > b/test/jdk/com/sun/jdi/DebuggerThreadTest.java > --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java > +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java > @@ -77,7 +77,8 @@ > ?????????int gotThreads = tg.enumerate(list, true); > ?????????for (int i = 0; i < Math.min(gotThreads, list.length); i++){ > ?????????????Thread t = list[i]; > - String groupName = t.getThreadGroup().getName(); > + ThreadGroup tga = t.getThreadGroup(); > + String groupName = (tga == null ? "": tga.getName()); > > ?????????????System.out.println("Thread [" + i + "] group = '" + > ????????????????????????????????groupName + From serguei.spitsyn at oracle.com Tue Sep 4 17:59:37 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Sep 2018 10:59:37 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B8E78F1.3080205@oracle.com> References: <5B8E78F1.3080205@oracle.com> Message-ID: <0e8b4e10-9692-4ef4-2c65-9f484e4705c8@oracle.com> Hi Gary, I'm Okay with this fix. Thanks, Serguei On 9/4/18 05:22, Gary Adams wrote: > Here's a quick fix to avoid the NPE using a getThreadGroup() which > could be null > if the thread has terminated. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 > > diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java > b/test/jdk/com/sun/jdi/DebuggerThreadTest.java > --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java > +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java > @@ -77,7 +77,8 @@ > ?????????int gotThreads = tg.enumerate(list, true); > ?????????for (int i = 0; i < Math.min(gotThreads, list.length); i++){ > ?????????????Thread t = list[i]; > - String groupName = t.getThreadGroup().getName(); > + ThreadGroup tga = t.getThreadGroup(); > + String groupName = (tga == null ? "": tga.getName()); > > ?????????????System.out.println("Thread [" + i + "] group = '" + > ????????????????????????????????groupName + From alexey.menkov at oracle.com Tue Sep 4 18:01:09 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 4 Sep 2018 11:01:09 -0700 Subject: RFR JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 In-Reply-To: References: <30a3895e-4e70-ed77-8da7-0ed4bfa47ae8@oracle.com> <34895282-5e70-dc17-2926-0bcd2dc2eeec@oracle.com> <5d625ee0-356e-380f-b1b3-b28c7010d931@oracle.com> Message-ID: Hi Chris, fixed. Updated webrev: http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.04/ On 08/31/2018 15:53, Chris Plummer wrote: > Hi Alex, > > Overall it looks good. > > ?159???? // jdb prompt when debuggee is not started nor suspended after > breakpoint > > How about "and is not suspended". And I'm not so sure the "after > breakpoint" is needed. Jdb always suspends after a breakpoint. > Eventually the user does a "cont", and after that I think you always see > the simple prompt "> " because after the "cont" the debuggee is not > suspended anymore. > > I'm just now realizing that there is a lot of replication of prompt > related code in the vmTestBase version of Jdb.java. Maybe that's > something we can address in the future. Because the classes have similar functionality. Initially it was planned to use vmTestBase classes to shell->java test conversion, but I was told by SQE that vmTestBase tests have too many issues and need to be reworked (moving them to appropriate locations). --alex > > thanks, > > Chris > > On 8/31/18 11:46 AM, Alex Menkov wrote: >> The latest webrev: >> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.03/ >> >> --alex >> >> On 08/31/2018 10:49, Alex Menkov wrote: >>> Hi Jc, >>> >>> On 08/31/2018 10:25, JC Beyler wrote: >>>> Hi Alexey, >>>> >>>> Apart from Serguei's comment above, I only saw two nits: >>>> >>>> A) The shorthand >>>> >>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/lib/jdb/JdbTest.java.udiff.html >>>> >>>> >>>> ?? 1) typo shortland -> shorthand >>>> ?? 2) could we just have a method instead of the shorthand? ie: >>>> instead of: >>>> +? ? protected final String debuggeeClass;? ?// shortland for >>>> launchOptions.debuggeeClass >>>> >>>> we have: >>>> +? ? protected String debuggeeClass() { return >>>> launchOptions.debuggeeClass; } >>>> >>>> Somehow, even as a final, duplication of data seems weird to me. (On >>>> the other hand, it seems you only use launchOptions.debuggeeClass in >>>> two spots in the code and once you used the shorthand and once you >>>> didn't. So perhaps no shorthand at all makes sense?) >>> >>> Yes, agree - there is no sense to have the field. >>> >>>> >>>> B) Not testing the command that works? >>>> >>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NotAField.java.udiff.html >>>> >>>> >>>> -> I'm surprised we are testing a command that should work and then >>>> a command that should not but only are checking the failing >>>> command's output. I know this is a direct translation of the test >>>> but it seems weird to not be testing also the hashCode() call, no? >>> >>> The original issue (https://bugs.openjdk.java.net/browse/JDK-4467887) >>> is about "more graceful message when user tries to evaluate a method >>> such as length() or toString() as a field". >>> So actually this "correct" command is not needed (I suppose the >>> command is executed just because test example in the bug contains it >>> for comparison) >>> >>> I'll do a test run and then upload new webrev. >>> >>> --alex >>> >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>>> On Thu, Aug 30, 2018 at 11:13 PM serguei.spitsyn at oracle.com >>>> >>> > wrote: >>>> >>>> ??? Hi Alex, >>>> >>>> ??? It looks good in general but not sure I understand all the changes. >>>> ??? Could you, please, tell a little bit more about the refactoring in >>>> ??? the Jdb.java and JdbTest.java? >>>> ??? I understand that you moved some code from Jdb.java to >>>> JdbTest.java. >>>> ??? But it is hard to track all of these move details. >>>> ??? What was the main refactoring logic? >>>> >>>> ??? Some comments on this update: >>>> >>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NullLocalVariable.java.frames.html >>>> >>>> >>>> >>>> >>>> ??? 30 * @library /test/lib >>>> ??? 31 * @compile -g JdbExprTest.java >>>> ??? 32 * @run main/othervm JdbExprTest >>>> >>>> ???? ? Why the class 'JdbExprTest' is used above? >>>> ???? ? Should it be the 'NullLocalVariable' instead? >>>> >>>> ??? Thanks, >>>> ??? Serguei >>>> >>>> >>>> ??? On 8/30/18 16:27, Alex Menkov wrote: >>>>> ??? Hi all, >>>>> >>>>> ??? Please review a fix for >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8210243 >>>>> ??? webrev: >>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/ >>>>> >>>>> >>>>> ??? The fix converts the following tests: >>>>> ??? - test/jdk/com/sun/jdi/JdbArgTest.sh >>>>> ??? - test/jdk/com/sun/jdi/JdbLockTest.sh >>>>> ??? - test/jdk/com/sun/jdi/JdbMissStep.sh >>>>> ??? - test/jdk/com/sun/jdi/JdbVarargsTest.sh >>>>> ??? - test/jdk/com/sun/jdi/MixedSuspendTest.sh >>>>> ??? - test/jdk/com/sun/jdi/NotAField.sh >>>>> ??? - test/jdk/com/sun/jdi/NullLocalVariable.sh >>>>> >>>>> ??? JdbArgTest requires to run only jdb (without debuggee), so Jdb >>>>> ??? class was decoupled - it now contains only jdb logic, debuggee >>>>> ??? logic was moved to JdbTest. >>>>> >>>>> ??? --alex >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc > > > From chris.plummer at oracle.com Tue Sep 4 18:09:58 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 4 Sep 2018 11:09:58 -0700 Subject: RFR JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 In-Reply-To: References: <30a3895e-4e70-ed77-8da7-0ed4bfa47ae8@oracle.com> <34895282-5e70-dc17-2926-0bcd2dc2eeec@oracle.com> <5d625ee0-356e-380f-b1b3-b28c7010d931@oracle.com> Message-ID: Looks good. Chris On 9/4/18 11:01 AM, Alex Menkov wrote: > Hi Chris, > > fixed. > Updated webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.04/ > > > On 08/31/2018 15:53, Chris Plummer wrote: >> Hi Alex, >> >> Overall it looks good. >> >> ??159???? // jdb prompt when debuggee is not started nor suspended >> after breakpoint >> >> How about "and is not suspended". And I'm not so sure the "after >> breakpoint" is needed. Jdb always suspends after a breakpoint. >> Eventually the user does a "cont", and after that I think you always >> see the simple prompt "> " because after the "cont" the debuggee is >> not suspended anymore. >> >> I'm just now realizing that there is a lot of replication of prompt >> related code in the vmTestBase version of Jdb.java. Maybe that's >> something we can address in the future. > > Because the classes have similar functionality. > Initially it was planned to use vmTestBase classes to shell->java test > conversion, but I was told by SQE that vmTestBase tests have too many > issues and need to be reworked (moving them to appropriate locations). > > --alex > >> >> thanks, >> >> Chris >> >> On 8/31/18 11:46 AM, Alex Menkov wrote: >>> The latest webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.03/ >>> >>> --alex >>> >>> On 08/31/2018 10:49, Alex Menkov wrote: >>>> Hi Jc, >>>> >>>> On 08/31/2018 10:25, JC Beyler wrote: >>>>> Hi Alexey, >>>>> >>>>> Apart from Serguei's comment above, I only saw two nits: >>>>> >>>>> A) The shorthand >>>>> >>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/lib/jdb/JdbTest.java.udiff.html >>>>> >>>>> >>>>> ?? 1) typo shortland -> shorthand >>>>> ?? 2) could we just have a method instead of the shorthand? ie: >>>>> instead of: >>>>> +? ? protected final String debuggeeClass;? ?// shortland for >>>>> launchOptions.debuggeeClass >>>>> >>>>> we have: >>>>> +? ? protected String debuggeeClass() { return >>>>> launchOptions.debuggeeClass; } >>>>> >>>>> Somehow, even as a final, duplication of data seems weird to me. >>>>> (On the other hand, it seems you only use >>>>> launchOptions.debuggeeClass in two spots in the code and once you >>>>> used the shorthand and once you didn't. So perhaps no shorthand at >>>>> all makes sense?) >>>> >>>> Yes, agree - there is no sense to have the field. >>>> >>>>> >>>>> B) Not testing the command that works? >>>>> >>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NotAField.java.udiff.html >>>>> >>>>> >>>>> -> I'm surprised we are testing a command that should work and >>>>> then a command that should not but only are checking the failing >>>>> command's output. I know this is a direct translation of the test >>>>> but it seems weird to not be testing also the hashCode() call, no? >>>> >>>> The original issue >>>> (https://bugs.openjdk.java.net/browse/JDK-4467887) is about "more >>>> graceful message when user tries to evaluate a method such as >>>> length() or toString() as a field". >>>> So actually this "correct" command is not needed (I suppose the >>>> command is executed just because test example in the bug contains >>>> it for comparison) >>>> >>>> I'll do a test run and then upload new webrev. >>>> >>>> --alex >>>> >>>>> >>>>> Thanks, >>>>> Jc >>>>> >>>>> >>>>> >>>>> On Thu, Aug 30, 2018 at 11:13 PM serguei.spitsyn at oracle.com >>>>> >>>> > wrote: >>>>> >>>>> ??? Hi Alex, >>>>> >>>>> ??? It looks good in general but not sure I understand all the >>>>> changes. >>>>> ??? Could you, please, tell a little bit more about the >>>>> refactoring in >>>>> ??? the Jdb.java and JdbTest.java? >>>>> ??? I understand that you moved some code from Jdb.java to >>>>> JdbTest.java. >>>>> ??? But it is hard to track all of these move details. >>>>> ??? What was the main refactoring logic? >>>>> >>>>> ??? Some comments on this update: >>>>> >>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NullLocalVariable.java.frames.html >>>>> >>>>> >>>>> >>>>> >>>>> ??? 30 * @library /test/lib >>>>> ??? 31 * @compile -g JdbExprTest.java >>>>> ??? 32 * @run main/othervm JdbExprTest >>>>> >>>>> ???? ? Why the class 'JdbExprTest' is used above? >>>>> ???? ? Should it be the 'NullLocalVariable' instead? >>>>> >>>>> ??? Thanks, >>>>> ??? Serguei >>>>> >>>>> >>>>> ??? On 8/30/18 16:27, Alex Menkov wrote: >>>>>> ??? Hi all, >>>>>> >>>>>> ??? Please review a fix for >>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8210243 >>>>>> ??? webrev: >>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/ >>>>>> >>>>>> >>>>>> ??? The fix converts the following tests: >>>>>> ??? - test/jdk/com/sun/jdi/JdbArgTest.sh >>>>>> ??? - test/jdk/com/sun/jdi/JdbLockTest.sh >>>>>> ??? - test/jdk/com/sun/jdi/JdbMissStep.sh >>>>>> ??? - test/jdk/com/sun/jdi/JdbVarargsTest.sh >>>>>> ??? - test/jdk/com/sun/jdi/MixedSuspendTest.sh >>>>>> ??? - test/jdk/com/sun/jdi/NotAField.sh >>>>>> ??? - test/jdk/com/sun/jdi/NullLocalVariable.sh >>>>>> >>>>>> ??? JdbArgTest requires to run only jdb (without debuggee), so Jdb >>>>>> ??? class was decoupled - it now contains only jdb logic, debuggee >>>>>> ??? logic was moved to JdbTest. >>>>>> >>>>>> ??? --alex >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >> >> >> From gary.adams at oracle.com Tue Sep 4 18:14:22 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 04 Sep 2018 14:14:22 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: References: <5B8E78F1.3080205@oracle.com> Message-ID: <5B8ECB7E.1000901@oracle.com> I'm not sure which thread exited causes the NPE. This patch will let the test continue and at least let the list of threads be processed. The test walks up the parents to the initial thread and then "enumerates()" the set of the threads to check. There is an inherent race condition in enumerate() that recognizes it is a snapshot of a moving target. On 9/4/18, 1:51 PM, Chris Plummer wrote: > Hi Gary, > > Why has the thread exited if the debuggee is still running? > > Chris > > On 9/4/18 5:22 AM, Gary Adams wrote: >> Here's a quick fix to avoid the NPE using a getThreadGroup() which >> could be null >> if the thread has terminated. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >> >> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> @@ -77,7 +77,8 @@ >> int gotThreads = tg.enumerate(list, true); >> for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >> Thread t = list[i]; >> - String groupName = t.getThreadGroup().getName(); >> + ThreadGroup tga = t.getThreadGroup(); >> + String groupName = (tga == null ? "": tga.getName()); >> >> System.out.println("Thread [" + i + "] group = '" + >> groupName + > > From chris.plummer at oracle.com Tue Sep 4 18:16:41 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 4 Sep 2018 11:16:41 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B8ECB7E.1000901@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> Message-ID: <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> Can you reproduce the problem? If so, maybe to find out which thread is a problem you could check for null, print the thread info, and then fail the test. Chris On 9/4/18 11:14 AM, Gary Adams wrote: > I'm not sure which thread exited causes the NPE. > This patch will let? the test continue and at least > let the list of threads be processed. > > The test walks up the parents to the initial thread > and then "enumerates()" the set of the threads to check. > There is an inherent race condition in enumerate() > that recognizes it is a snapshot of a moving target. > > On 9/4/18, 1:51 PM, Chris Plummer wrote: >> Hi Gary, >> >> Why has the thread exited if the debuggee is still running? >> >> Chris >> >> On 9/4/18 5:22 AM, Gary Adams wrote: >>> Here's a quick fix to avoid the NPE using a getThreadGroup() which >>> could be null >>> if the thread has terminated. >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>> >>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> @@ -77,7 +77,8 @@ >>> ???????? int gotThreads = tg.enumerate(list, true); >>> ???????? for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >>> ???????????? Thread t = list[i]; >>> - String groupName = t.getThreadGroup().getName(); >>> + ThreadGroup tga = t.getThreadGroup(); >>> + String groupName = (tga == null ? "": tga.getName()); >>> >>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>> ??????????????????????????????? groupName + >> >> > From gary.adams at oracle.com Tue Sep 4 18:28:46 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 04 Sep 2018 14:28:46 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> Message-ID: <5B8ECEDE.2040708@oracle.com> I haven't been able to reproduce the problem locally. Trying larger test runs on mach5 now. Here's the output from a successful test run. If any of the threads exited, they would have a null group name. Howdy! Thread [0] group = 'system' name = 'Reference Handler' daemon = true Thread [1] group = 'system' name = 'Finalizer' daemon = true Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true Thread [3] group = 'system' name = 'process reaper' daemon = true Thread [4] group = 'main' name = 'main' daemon = false Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' daemon = false Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' daemon = false Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' daemon = false Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon = true Thread [10] group = 'InnocuousThreadGroup' name = 'Common-Cleaner' daemon = true Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event Handler' daemon = true Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM Interface' daemon = true Goodbye from DebuggerThreadTarg! On 9/4/18, 2:16 PM, Chris Plummer wrote: > Can you reproduce the problem? If so, maybe to find out which thread > is a problem you could check for null, print the thread info, and then > fail the test. > > Chris > > On 9/4/18 11:14 AM, Gary Adams wrote: >> I'm not sure which thread exited causes the NPE. >> This patch will let the test continue and at least >> let the list of threads be processed. >> >> The test walks up the parents to the initial thread >> and then "enumerates()" the set of the threads to check. >> There is an inherent race condition in enumerate() >> that recognizes it is a snapshot of a moving target. >> >> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> Why has the thread exited if the debuggee is still running? >>> >>> Chris >>> >>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>> Here's a quick fix to avoid the NPE using a getThreadGroup() which >>>> could be null >>>> if the thread has terminated. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>> >>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> @@ -77,7 +77,8 @@ >>>> int gotThreads = tg.enumerate(list, true); >>>> for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >>>> Thread t = list[i]; >>>> - String groupName = t.getThreadGroup().getName(); >>>> + ThreadGroup tga = t.getThreadGroup(); >>>> + String groupName = (tga == null ? "": tga.getName()); >>>> >>>> System.out.println("Thread [" + i + "] group = '" + >>>> groupName + >>> >>> >> > > From chris.plummer at oracle.com Tue Sep 4 19:15:13 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 4 Sep 2018 12:15:13 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B8ECEDE.2040708@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> Message-ID: Hi Gary, The failed case only had: Thread [0] group = 'system' name = 'Reference Handler' daemon = true Thread [1] group = 'system' name = 'Finalizer' daemon = true Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true Thread [3] group = 'system' name = 'process reaper' daemon = true That would indicate that 'main' is likely the thread that exited. Seems odd. Isn't that the thread that the test is executing in? If you can't reproduce it, maybe it would be better to commit a diagnostic fix like the one I suggested and keep an eye on it. However, it only seems to have failed once due to this reason, so unless it is a new problem we may never see it again. Chris On 9/4/18 11:28 AM, Gary Adams wrote: > I haven't been able to reproduce the problem locally. > Trying larger test runs on mach5 now. > > Here's the output from a successful test run. > If any of the threads exited, they would have a null group name. > > Howdy! > Thread [0] group = 'system' name = 'Reference Handler' daemon = true > Thread [1] group = 'system' name = 'Finalizer' daemon = true > Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true > Thread [3] group = 'system' name = 'process reaper' daemon = true > Thread [4] group = 'main' name = 'main' daemon = false > Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true > Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' daemon > = false > Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' daemon > = false > Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' daemon > = false > Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon = true > Thread [10] group = 'InnocuousThreadGroup' name = 'Common-Cleaner' > daemon = true > Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event > Handler' daemon = true > Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM > Interface' daemon = true > Goodbye from DebuggerThreadTarg! > > > On 9/4/18, 2:16 PM, Chris Plummer wrote: >> Can you reproduce the problem? If so, maybe to find out which thread >> is a problem you could check for null, print the thread info, and >> then fail the test. >> >> Chris >> >> On 9/4/18 11:14 AM, Gary Adams wrote: >>> I'm not sure which thread exited causes the NPE. >>> This patch will let? the test continue and at least >>> let the list of threads be processed. >>> >>> The test walks up the parents to the initial thread >>> and then "enumerates()" the set of the threads to check. >>> There is an inherent race condition in enumerate() >>> that recognizes it is a snapshot of a moving target. >>> >>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> Why has the thread exited if the debuggee is still running? >>>> >>>> Chris >>>> >>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() which >>>>> could be null >>>>> if the thread has terminated. >>>>> >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>> >>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> @@ -77,7 +77,8 @@ >>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>> ???????? for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >>>>> ???????????? Thread t = list[i]; >>>>> - String groupName = t.getThreadGroup().getName(); >>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>> + String groupName = (tga == null ? "": tga.getName()); >>>>> >>>>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>>>> ??????????????????????????????? groupName + >>>> >>>> >>> >> >> > From serguei.spitsyn at oracle.com Tue Sep 4 19:22:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Sep 2018 12:22:52 -0700 Subject: RFR JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 In-Reply-To: <9cfa36eb-efa7-ef44-fffc-17018fa24ce2@oracle.com> References: <30a3895e-4e70-ed77-8da7-0ed4bfa47ae8@oracle.com> <9cfa36eb-efa7-ef44-fffc-17018fa24ce2@oracle.com> Message-ID: Hi Alex, Thank you for the explanations and update! Thanks, Serguei On 8/31/18 10:26, Alex Menkov wrote: > Hi Serguei, > > On 08/30/2018 23:12, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> It looks good in general but not sure I understand all the changes. >> Could you, please, tell a little bit more about the refactoring in >> the Jdb.java and JdbTest.java? >> I understand that you moved some code from Jdb.java to JdbTest.java. >> But it is hard to track all of these move details. >> What was the main refactoring logic? > > Before the fix Jdb class contained logic to launch debuggee, parse > listening port for debugger and run jdb connecting to the port. > Now it contains only jdb-related code. > Debuggee-related code is moved to JdbTest (including LaunchOptions > inner class which contains info about debuggee main class and options). > I thought about moving debuggee-related code to dedicated class > (Debuggee), but it's quite small amount of code (main part is > implemented in jdk.test.lib.process.ProcessTools) and I don't see any > chance the class can be reused. > >> >> Some comments on this update: >> >> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NullLocalVariable.java.frames.html >> >> >> 30 * @library /test/lib >> 31 * @compile -g JdbExprTest.java >> 32 * @run main/othervm JdbExprTest >> >> ?? Why the class 'JdbExprTest' is used above? >> ?? Should it be the 'NullLocalVariable' instead? > > Good catch! > Fixed. > updated webrev: > cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.02/ > > --alex > >> >> Thanks, >> Serguei >> >> >> On 8/30/18 16:27, Alex Menkov wrote: >>> Hi all, >>> >>> Please review a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8210243 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/ >>> >>> The fix converts the following tests: >>> - test/jdk/com/sun/jdi/JdbArgTest.sh >>> - test/jdk/com/sun/jdi/JdbLockTest.sh >>> - test/jdk/com/sun/jdi/JdbMissStep.sh >>> - test/jdk/com/sun/jdi/JdbVarargsTest.sh >>> - test/jdk/com/sun/jdi/MixedSuspendTest.sh >>> - test/jdk/com/sun/jdi/NotAField.sh >>> - test/jdk/com/sun/jdi/NullLocalVariable.sh >>> >>> JdbArgTest requires to run only jdb (without debuggee), so Jdb class >>> was decoupled - it now contains only jdb logic, debuggee logic was >>> moved to JdbTest. >>> >>> --alex >> From serguei.spitsyn at oracle.com Tue Sep 4 19:28:12 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Sep 2018 12:28:12 -0700 Subject: RFR JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 In-Reply-To: References: <30a3895e-4e70-ed77-8da7-0ed4bfa47ae8@oracle.com> <34895282-5e70-dc17-2926-0bcd2dc2eeec@oracle.com> <5d625ee0-356e-380f-b1b3-b28c7010d931@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Tue Sep 4 21:30:25 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 4 Sep 2018 14:30:25 -0700 Subject: RFR JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 In-Reply-To: References: <30a3895e-4e70-ed77-8da7-0ed4bfa47ae8@oracle.com> <34895282-5e70-dc17-2926-0bcd2dc2eeec@oracle.com> <5d625ee0-356e-380f-b1b3-b28c7010d931@oracle.com> Message-ID: Hi Serguei, sleepcmd is empty, so it's NOP. --alex On 09/04/2018 12:28, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > It looks good. > Just one minor question. > > http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.04/test/jdk/com/sun/jdi/NullLocalVariable.java.udiff.html > > -dojdbCmds() > -{ > - #set -x > - cmd stop at badscope:4 ; $sleepcmd > - runToBkpt ; $sleepcmd > - cmd next ; $sleepcmd > - cmd next ; $sleepcmd > - cmd locals ; $sleepcmd > - cmd allowExit cont > -} > > The original test had a $sleepcmd after each jdb command. > New code does not have anything like this. > Is it intentional or overlooked? > In fact, I do not remember and have just some guess what is the $sleepcmd. > > Thanks, > Serguei > > > On 9/4/18 11:01, Alex Menkov wrote: >> Hi Chris, >> >> fixed. >> Updated webrev: >> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.04/ >> >> >> On 08/31/2018 15:53, Chris Plummer wrote: >>> Hi Alex, >>> >>> Overall it looks good. >>> >>> ??159???? // jdb prompt when debuggee is not started nor suspended >>> after breakpoint >>> >>> How about "and is not suspended". And I'm not so sure the "after >>> breakpoint" is needed. Jdb always suspends after a breakpoint. >>> Eventually the user does a "cont", and after that I think you always >>> see the simple prompt "> " because after the "cont" the debuggee is >>> not suspended anymore. >>> >>> I'm just now realizing that there is a lot of replication of prompt >>> related code in the vmTestBase version of Jdb.java. Maybe that's >>> something we can address in the future. >> >> Because the classes have similar functionality. >> Initially it was planned to use vmTestBase classes to shell->java test >> conversion, but I was told by SQE that vmTestBase tests have too many >> issues and need to be reworked (moving them to appropriate locations). >> >> --alex >> >>> >>> thanks, >>> >>> Chris >>> >>> On 8/31/18 11:46 AM, Alex Menkov wrote: >>>> The latest webrev: >>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.03/ >>>> >>>> --alex >>>> >>>> On 08/31/2018 10:49, Alex Menkov wrote: >>>>> Hi Jc, >>>>> >>>>> On 08/31/2018 10:25, JC Beyler wrote: >>>>>> Hi Alexey, >>>>>> >>>>>> Apart from Serguei's comment above, I only saw two nits: >>>>>> >>>>>> A) The shorthand >>>>>> >>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/lib/jdb/JdbTest.java.udiff.html >>>>>> >>>>>> >>>>>> ?? 1) typo shortland -> shorthand >>>>>> ?? 2) could we just have a method instead of the shorthand? ie: >>>>>> instead of: >>>>>> +? ? protected final String debuggeeClass;? ?// shortland for >>>>>> launchOptions.debuggeeClass >>>>>> >>>>>> we have: >>>>>> +? ? protected String debuggeeClass() { return >>>>>> launchOptions.debuggeeClass; } >>>>>> >>>>>> Somehow, even as a final, duplication of data seems weird to me. >>>>>> (On the other hand, it seems you only use >>>>>> launchOptions.debuggeeClass in two spots in the code and once you >>>>>> used the shorthand and once you didn't. So perhaps no shorthand at >>>>>> all makes sense?) >>>>> >>>>> Yes, agree - there is no sense to have the field. >>>>> >>>>>> >>>>>> B) Not testing the command that works? >>>>>> >>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NotAField.java.udiff.html >>>>>> >>>>>> >>>>>> -> I'm surprised we are testing a command that should work and >>>>>> then a command that should not but only are checking the failing >>>>>> command's output. I know this is a direct translation of the test >>>>>> but it seems weird to not be testing also the hashCode() call, no? >>>>> >>>>> The original issue >>>>> (https://bugs.openjdk.java.net/browse/JDK-4467887) is about "more >>>>> graceful message when user tries to evaluate a method such as >>>>> length() or toString() as a field". >>>>> So actually this "correct" command is not needed (I suppose the >>>>> command is executed just because test example in the bug contains >>>>> it for comparison) >>>>> >>>>> I'll do a test run and then upload new webrev. >>>>> >>>>> --alex >>>>> >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Aug 30, 2018 at 11:13 PM serguei.spitsyn at oracle.com >>>>>> >>>>> > wrote: >>>>>> >>>>>> ??? Hi Alex, >>>>>> >>>>>> ??? It looks good in general but not sure I understand all the >>>>>> changes. >>>>>> ??? Could you, please, tell a little bit more about the >>>>>> refactoring in >>>>>> ??? the Jdb.java and JdbTest.java? >>>>>> ??? I understand that you moved some code from Jdb.java to >>>>>> JdbTest.java. >>>>>> ??? But it is hard to track all of these move details. >>>>>> ??? What was the main refactoring logic? >>>>>> >>>>>> ??? Some comments on this update: >>>>>> >>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NullLocalVariable.java.frames.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ??? 30 * @library /test/lib >>>>>> ??? 31 * @compile -g JdbExprTest.java >>>>>> ??? 32 * @run main/othervm JdbExprTest >>>>>> >>>>>> ???? ? Why the class 'JdbExprTest' is used above? >>>>>> ???? ? Should it be the 'NullLocalVariable' instead? >>>>>> >>>>>> ??? Thanks, >>>>>> ??? Serguei >>>>>> >>>>>> >>>>>> ??? On 8/30/18 16:27, Alex Menkov wrote: >>>>>>> ??? Hi all, >>>>>>> >>>>>>> ??? Please review a fix for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210243 >>>>>>> ??? webrev: >>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/ >>>>>>> >>>>>>> >>>>>>> ??? The fix converts the following tests: >>>>>>> ??? - test/jdk/com/sun/jdi/JdbArgTest.sh >>>>>>> ??? - test/jdk/com/sun/jdi/JdbLockTest.sh >>>>>>> ??? - test/jdk/com/sun/jdi/JdbMissStep.sh >>>>>>> ??? - test/jdk/com/sun/jdi/JdbVarargsTest.sh >>>>>>> ??? - test/jdk/com/sun/jdi/MixedSuspendTest.sh >>>>>>> ??? - test/jdk/com/sun/jdi/NotAField.sh >>>>>>> ??? - test/jdk/com/sun/jdi/NullLocalVariable.sh >>>>>>> >>>>>>> ??? JdbArgTest requires to run only jdb (without debuggee), so Jdb >>>>>>> ??? class was decoupled - it now contains only jdb logic, debuggee >>>>>>> ??? logic was moved to JdbTest. >>>>>>> >>>>>>> ??? --alex >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc >>> >>> >>> > From serguei.spitsyn at oracle.com Tue Sep 4 22:30:11 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Sep 2018 15:30:11 -0700 Subject: RFR JDK-8210243: [TEST] rewrite com/sun/jdi shell tests to java version - step3 In-Reply-To: References: <30a3895e-4e70-ed77-8da7-0ed4bfa47ae8@oracle.com> <34895282-5e70-dc17-2926-0bcd2dc2eeec@oracle.com> <5d625ee0-356e-380f-b1b3-b28c7010d931@oracle.com> Message-ID: <7b21be96-80ce-5567-abce-2cd7d472402c@oracle.com> Okay, thanks! Serguei On 9/4/18 14:30, Alex Menkov wrote: > Hi Serguei, > > sleepcmd is empty, so it's NOP. > > --alex > > On 09/04/2018 12:28, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> It looks good. >> Just one minor question. >> >> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.04/test/jdk/com/sun/jdi/NullLocalVariable.java.udiff.html >> >> >> -dojdbCmds() >> -{ >> - #set -x >> - cmd stop at badscope:4 ; $sleepcmd >> - runToBkpt ; $sleepcmd >> - cmd next ; $sleepcmd >> - cmd next ; $sleepcmd >> - cmd locals ; $sleepcmd >> - cmd allowExit cont >> -} >> >> The original test had a $sleepcmd after each jdb command. >> New code does not have anything like this. >> Is it intentional or overlooked? >> In fact, I do not remember and have just some guess what is the >> $sleepcmd. >> >> Thanks, >> Serguei >> >> >> On 9/4/18 11:01, Alex Menkov wrote: >>> Hi Chris, >>> >>> fixed. >>> Updated webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.04/ >>> >>> >>> On 08/31/2018 15:53, Chris Plummer wrote: >>>> Hi Alex, >>>> >>>> Overall it looks good. >>>> >>>> ??159???? // jdb prompt when debuggee is not started nor suspended >>>> after breakpoint >>>> >>>> How about "and is not suspended". And I'm not so sure the "after >>>> breakpoint" is needed. Jdb always suspends after a breakpoint. >>>> Eventually the user does a "cont", and after that I think you >>>> always see the simple prompt "> " because after the "cont" the >>>> debuggee is not suspended anymore. >>>> >>>> I'm just now realizing that there is a lot of replication of prompt >>>> related code in the vmTestBase version of Jdb.java. Maybe that's >>>> something we can address in the future. >>> >>> Because the classes have similar functionality. >>> Initially it was planned to use vmTestBase classes to shell->java >>> test conversion, but I was told by SQE that vmTestBase tests have >>> too many issues and need to be reworked (moving them to appropriate >>> locations). >>> >>> --alex >>> >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 8/31/18 11:46 AM, Alex Menkov wrote: >>>>> The latest webrev: >>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.03/ >>>>> >>>>> --alex >>>>> >>>>> On 08/31/2018 10:49, Alex Menkov wrote: >>>>>> Hi Jc, >>>>>> >>>>>> On 08/31/2018 10:25, JC Beyler wrote: >>>>>>> Hi Alexey, >>>>>>> >>>>>>> Apart from Serguei's comment above, I only saw two nits: >>>>>>> >>>>>>> A) The shorthand >>>>>>> >>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/lib/jdb/JdbTest.java.udiff.html >>>>>>> >>>>>>> >>>>>>> ?? 1) typo shortland -> shorthand >>>>>>> ?? 2) could we just have a method instead of the shorthand? ie: >>>>>>> instead of: >>>>>>> +? ? protected final String debuggeeClass;? ?// shortland for >>>>>>> launchOptions.debuggeeClass >>>>>>> >>>>>>> we have: >>>>>>> +? ? protected String debuggeeClass() { return >>>>>>> launchOptions.debuggeeClass; } >>>>>>> >>>>>>> Somehow, even as a final, duplication of data seems weird to me. >>>>>>> (On the other hand, it seems you only use >>>>>>> launchOptions.debuggeeClass in two spots in the code and once >>>>>>> you used the shorthand and once you didn't. So perhaps no >>>>>>> shorthand at all makes sense?) >>>>>> >>>>>> Yes, agree - there is no sense to have the field. >>>>>> >>>>>>> >>>>>>> B) Not testing the command that works? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NotAField.java.udiff.html >>>>>>> >>>>>>> >>>>>>> -> I'm surprised we are testing a command that should work and >>>>>>> then a command that should not but only are checking the failing >>>>>>> command's output. I know this is a direct translation of the >>>>>>> test but it seems weird to not be testing also the hashCode() >>>>>>> call, no? >>>>>> >>>>>> The original issue >>>>>> (https://bugs.openjdk.java.net/browse/JDK-4467887) is about "more >>>>>> graceful message when user tries to evaluate a method such as >>>>>> length() or toString() as a field". >>>>>> So actually this "correct" command is not needed (I suppose the >>>>>> command is executed just because test example in the bug contains >>>>>> it for comparison) >>>>>> >>>>>> I'll do a test run and then upload new webrev. >>>>>> >>>>>> --alex >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 30, 2018 at 11:13 PM serguei.spitsyn at oracle.com >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> ??? Hi Alex, >>>>>>> >>>>>>> ??? It looks good in general but not sure I understand all the >>>>>>> changes. >>>>>>> ??? Could you, please, tell a little bit more about the >>>>>>> refactoring in >>>>>>> ??? the Jdb.java and JdbTest.java? >>>>>>> ??? I understand that you moved some code from Jdb.java to >>>>>>> JdbTest.java. >>>>>>> ??? But it is hard to track all of these move details. >>>>>>> ??? What was the main refactoring logic? >>>>>>> >>>>>>> ??? Some comments on this update: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/test/jdk/com/sun/jdi/NullLocalVariable.java.frames.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ??? 30 * @library /test/lib >>>>>>> ??? 31 * @compile -g JdbExprTest.java >>>>>>> ??? 32 * @run main/othervm JdbExprTest >>>>>>> >>>>>>> ???? ? Why the class 'JdbExprTest' is used above? >>>>>>> ???? ? Should it be the 'NullLocalVariable' instead? >>>>>>> >>>>>>> ??? Thanks, >>>>>>> ??? Serguei >>>>>>> >>>>>>> >>>>>>> ??? On 8/30/18 16:27, Alex Menkov wrote: >>>>>>>> ??? Hi all, >>>>>>>> >>>>>>>> ??? Please review a fix for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210243 >>>>>>>> ??? webrev: >>>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step3/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> ??? The fix converts the following tests: >>>>>>>> ??? - test/jdk/com/sun/jdi/JdbArgTest.sh >>>>>>>> ??? - test/jdk/com/sun/jdi/JdbLockTest.sh >>>>>>>> ??? - test/jdk/com/sun/jdi/JdbMissStep.sh >>>>>>>> ??? - test/jdk/com/sun/jdi/JdbVarargsTest.sh >>>>>>>> ??? - test/jdk/com/sun/jdi/MixedSuspendTest.sh >>>>>>>> ??? - test/jdk/com/sun/jdi/NotAField.sh >>>>>>>> ??? - test/jdk/com/sun/jdi/NullLocalVariable.sh >>>>>>>> >>>>>>>> ??? JdbArgTest requires to run only jdb (without debuggee), so Jdb >>>>>>>> ??? class was decoupled - it now contains only jdb logic, debuggee >>>>>>>> ??? logic was moved to JdbTest. >>>>>>>> >>>>>>>> ??? --alex >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>> >>>> >>>> >> From jcbeyler at google.com Tue Sep 4 23:12:54 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 4 Sep 2018 16:12:54 -0700 Subject: RFR (M) 8210198: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[A-F] tests Message-ID: Hi all, Continuing the removal of the JNI_ENV* macros, I have done about half of the JVMTI Get[A-F] methods. The whole change for jvmti/GetXX tests was about 2k of changes so it seemed best to just divide it into two parts (from my approximation there will be 2 more webrevs to finish the umbrella item JDK-8209547). The change is straightforward as before, just a bit repetitive: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210198/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210198 I tested this in release mode for the tests that were modified. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Sep 5 00:10:29 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 4 Sep 2018 17:10:29 -0700 Subject: RFR (M) 8210198: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[A-F] tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Sep 5 01:33:07 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 4 Sep 2018 18:33:07 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools Message-ID: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > 2375 lines changed: 322 ins; 1662 del; 391 mod Hi all, could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process? there were a few differences b/w implementations which are addressed by the patch: - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them. - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest. the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible. webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html testing: tier1-tier3 + :jdk_svc JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 Thanks, -- Igor From jcbeyler at google.com Wed Sep 5 03:01:17 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 4 Sep 2018 20:01:17 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> Message-ID: Hi Igor, I reviewed the webrev but I noticed two things: - Small nit: - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then? - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html - Seems we could refactor a bit this no? - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized: class TaskStream { private final ByteArrayOutputStream buffer; private Future task; public TaskStream(InputStream stream) { buffer = new ByteArrayOutputStream(); task = new StreamPumper(stream, buffer).process(); } public String getBuffer() { try { task.get(); return buffer.toString(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new OutputBufferException(e); } catch (ExecutionException | CancellationException e) { throw new OutputBufferException(e); } } } + class LazyOutputBuffer implements OutputBuffer { + private final TaskStream stderr; + private final TaskStream stdout; + private final Process p;++ private LazyOutputBuffer(Process p) {+ this.p = p; + stderr = new TaskStream(p.getInputStream()); + stdout = new TaskStream(p.getErrorStream());+ }++ @Override+ public String getStdout() { + return stdout.getBuffer(); + }+ @Override+ public String getStderr() { + return stderr.getBuffer()+ } I think it is more clear, what do you think? Apart from those two elements, it looks good to me :), nice refactor! Jc On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > > 2375 lines changed: 322 ins; 1662 del; 391 mod > > Hi all, > > could you please review the patch which removes > jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages > w/ corresponding classes from jdk.test.lib.process? > > there were a few differences b/w implementations which are addressed by > the patch: > - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) > method > - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family > - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any > purposes, while j.t.OutputBuffer provided lazy access to a process's cout, > cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface > w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated > j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of > storing them. > - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but > j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests > which really depend on absence of '-cp' and updated them to create > ProcessBuilder directly, namely JavaClassPathTest and > AppendToClassPathModuleTest. > > the rest of the patch is straightforward change of used classes w/ adding > @library /test/lib if necessary and removing @library /lib/testlibrary if > possible. > > webrev: > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > testing: tier1-tier3 + :jdk_svc > JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 > > Thanks, > -- Igor > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From egor.ushakov at jetbrains.com Wed Sep 5 10:25:22 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 5 Sep 2018 13:25:22 +0300 Subject: Is it possible to resurrect sa-jdi? Message-ID: <572b960f-7354-aaea-435c-8764c8d9e845@jetbrains.com> Hi, suddenly at Jetbrains we realized that sa pid attach may be useful. Unfortunately sun.jvm.hotspot.jdi* was removed in jdk 9. We would like to resurrect sa-jdi in our jdk fork. As I can see the agent is still there, so it should be feasible. Do you see any issues with that? Should we go in that direction or is it a dead end? Thanks! -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From Alan.Bateman at oracle.com Wed Sep 5 10:47:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Sep 2018 11:47:23 +0100 Subject: Is it possible to resurrect sa-jdi? In-Reply-To: <572b960f-7354-aaea-435c-8764c8d9e845@jetbrains.com> References: <572b960f-7354-aaea-435c-8764c8d9e845@jetbrains.com> Message-ID: <2ae20af4-99c7-64af-6fa6-58ff836bdd0c@oracle.com> On 05/09/2018 11:25, Egor Ushakov wrote: > Hi, > > suddenly at Jetbrains we realized that sa pid attach may be useful. > Unfortunately sun.jvm.hotspot.jdi* was removed in jdk 9. > We would like to resurrect sa-jdi in our jdk fork. As I can see the > agent is still there, so it should be feasible. > Do you see any issues with that? Should we go in that direction or is > it a dead end? > There were discussions here in 2016 (and I think further back) about SA-JDI and whether it was actually used. I don't recall anyone responding or objecting at the time, probably because most developers would never attach a java debugger to a core file or hung VM. Have you seen significant usage from IntelliJ users? Are these users diagnosing VM crashes or other JDK bugs? As regards creating your own JDI connectors and transport then it should be feasible but it would rely on an undocumented and non-exported API. You would need to compile and run with --add-exports option to export the packages to whatever module contains the connectors for example. -Alan From egor.ushakov at jetbrains.com Wed Sep 5 11:44:52 2018 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 5 Sep 2018 14:44:52 +0300 Subject: Is it possible to resurrect sa-jdi? In-Reply-To: <2ae20af4-99c7-64af-6fa6-58ff836bdd0c@oracle.com> References: <572b960f-7354-aaea-435c-8764c8d9e845@jetbrains.com> <2ae20af4-99c7-64af-6fa6-58ff836bdd0c@oracle.com> Message-ID: <1a4fb900-192b-0c5b-b171-bc20ba4e7d82@jetbrains.com> Hi Alan, this is not yet released in IDEA, so no usage for now. However it looks much better than the usual thread dump, so if it could be used easily (and we're trying to achieve that) it could easily replace the thread dump action for processes in IDEA. On 05-Sep-18 13:47, Alan Bateman wrote: > On 05/09/2018 11:25, Egor Ushakov wrote: >> Hi, >> >> suddenly at Jetbrains we realized that sa pid attach may be useful. >> Unfortunately sun.jvm.hotspot.jdi* was removed in jdk 9. >> We would like to resurrect sa-jdi in our jdk fork. As I can see the >> agent is still there, so it should be feasible. >> Do you see any issues with that? Should we go in that direction or is >> it a dead end? >> > There were discussions here in 2016 (and I think further back) about > SA-JDI and whether it was actually used. I don't recall anyone > responding or objecting at the time, probably because most developers > would never attach a java debugger to a core file or hung VM. Have you > seen significant usage from IntelliJ users? Are these users diagnosing > VM crashes or other JDK bugs? > > As regards creating your own JDI connectors and transport then it > should be feasible but it would rely on an undocumented and > non-exported API. You would need to compile and run with --add-exports > option to export the packages to whatever module contains the > connectors for example. > > -Alan > -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From gary.adams at oracle.com Wed Sep 5 14:33:13 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 05 Sep 2018 10:33:13 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> Message-ID: <5B8FE929.9060203@oracle.com> The DebuggerThreadTest ensures it is in sync at the beginning of RunTests with a breakpoint event in DebuggerThreadTarg ready() method. The DebuggerThreadTest then continues with dumpThreads() and listenUntilVMDisconnect() completes. If the DebugThreadTarg is resumed prematurely, the main thread in the debuggee could complete before the dumpThreads enumeration is complete. DebuggerThreadTest main() startTests() runTests() startTo( "DebuggerThreadTarg.ready()") dumpThreads() listenUntilVMDisconnect() DebuggerThreadTarg main() ready() Revised fix: - Prevents the NPE from a finished thread group - Fails the test with a message indicating number of premature completed threads. diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java b/test/jdk/com/sun/jdi/DebuggerThreadTest.java --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -76,8 +76,16 @@ Thread list[] = new Thread[listThreads * 2]; int gotThreads = tg.enumerate(list, true); for (int i = 0; i < Math.min(gotThreads, list.length); i++){ + int finishedThreads = 0; Thread t = list[i]; - String groupName = t.getThreadGroup().getName(); + ThreadGroup tga = t.getThreadGroup(); + String groupName; + if (tga == null) { + groupName = ""; + finishedThreads++ ; + } else { + groupName =tga.getName(); + } System.out.println("Thread [" + i + "] group = '" + groupName + @@ -89,7 +97,10 @@ failure("FAIL: non-daemon thread '" + t.getName() + "' found in ThreadGroup '" + groupName + "'"); } - + if (finishedThreads > 0 ) { + failure("FAIL: " + finishedThreads + + " threads completed while VM suspended."); + } } } On 9/4/18, 3:15 PM, Chris Plummer wrote: > Hi Gary, > > The failed case only had: > > Thread [0] group = 'system' name = 'Reference Handler' daemon = true > Thread [1] group = 'system' name = 'Finalizer' daemon = true > Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true > Thread [3] group = 'system' name = 'process reaper' daemon = true > > That would indicate that 'main' is likely the thread that exited. > Seems odd. Isn't that the thread that the test is executing in? > > If you can't reproduce it, maybe it would be better to commit a > diagnostic fix like the one I suggested and keep an eye on it. > However, it only seems to have failed once due to this reason, so > unless it is a new problem we may never see it again. > > Chris > > On 9/4/18 11:28 AM, Gary Adams wrote: >> I haven't been able to reproduce the problem locally. >> Trying larger test runs on mach5 now. >> >> Here's the output from a successful test run. >> If any of the threads exited, they would have a null group name. >> >> Howdy! >> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >> Thread [1] group = 'system' name = 'Finalizer' daemon = true >> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >> Thread [3] group = 'system' name = 'process reaper' daemon = true >> Thread [4] group = 'main' name = 'main' daemon = false >> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' daemon >> = false >> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' daemon >> = false >> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' daemon >> = false >> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon = true >> Thread [10] group = 'InnocuousThreadGroup' name = 'Common-Cleaner' >> daemon = true >> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event >> Handler' daemon = true >> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >> Interface' daemon = true >> Goodbye from DebuggerThreadTarg! >> >> >> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>> Can you reproduce the problem? If so, maybe to find out which thread >>> is a problem you could check for null, print the thread info, and >>> then fail the test. >>> >>> Chris >>> >>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>> I'm not sure which thread exited causes the NPE. >>>> This patch will let the test continue and at least >>>> let the list of threads be processed. >>>> >>>> The test walks up the parents to the initial thread >>>> and then "enumerates()" the set of the threads to check. >>>> There is an inherent race condition in enumerate() >>>> that recognizes it is a snapshot of a moving target. >>>> >>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> Why has the thread exited if the debuggee is still running? >>>>> >>>>> Chris >>>>> >>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() >>>>>> which could be null >>>>>> if the thread has terminated. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>> >>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> @@ -77,7 +77,8 @@ >>>>>> int gotThreads = tg.enumerate(list, true); >>>>>> for (int i = 0; i < Math.min(gotThreads, list.length); >>>>>> i++){ >>>>>> Thread t = list[i]; >>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>> + String groupName = (tga == null ? "": tga.getName()); >>>>>> >>>>>> System.out.println("Thread [" + i + "] group = '" + >>>>>> groupName + >>>>> >>>>> >>>> >>> >>> >> > > From ecki at zusammenkunft.net Wed Sep 5 17:22:31 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 5 Sep 2018 17:22:31 +0000 Subject: Is it possible to resurrect sa-jdi? In-Reply-To: <2ae20af4-99c7-64af-6fa6-58ff836bdd0c@oracle.com> References: <572b960f-7354-aaea-435c-8764c8d9e845@jetbrains.com>, <2ae20af4-99c7-64af-6fa6-58ff836bdd0c@oracle.com> Message-ID: I thought by providing jhsdb launcher the usage of dump based analysis became more prominent, so those attach mechanisms are not going away, right? -- https://Bernd.eckenfels.net ________________________________ Von: -800456320m Auftrag von Gesendet: Mittwoch, September 5, 2018 1:17 PM An: Egor Ushakov; serviceability-dev at openjdk.java.net Betreff: Re: Is it possible to resurrect sa-jdi? On 05/09/2018 11:25, Egor Ushakov wrote: > Hi, > > suddenly at Jetbrains we realized that sa pid attach may be useful. > Unfortunately sun.jvm.hotspot.jdi* was removed in jdk 9. > We would like to resurrect sa-jdi in our jdk fork. As I can see the > agent is still there, so it should be feasible. > Do you see any issues with that? Should we go in that direction or is > it a dead end? > There were discussions here in 2016 (and I think further back) about SA-JDI and whether it was actually used. I don't recall anyone responding or objecting at the time, probably because most developers would never attach a java debugger to a core file or hung VM. Have you seen significant usage from IntelliJ users? Are these users diagnosing VM crashes or other JDK bugs? As regards creating your own JDI connectors and transport then it should be feasible but it would rely on an undocumented and non-exported API. You would need to compile and run with --add-exports option to export the packages to whatever module contains the connectors for example. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 5 18:07:52 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 11:07:52 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B8FE929.9060203@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> Message-ID: Hi Gary, > If the DebugThreadTarg is resumed prematurely, The failure explanation seems to hinge on this, but I don't see how this can happen. What is resuming DebugThreadTarg? Only the call to listenUntilVMDisconnect() should be doing this, and we aren't even getting that far. The only thing I can think of is due to some other issue (maybe host out of memory so process was killed off), the DebugThreadTarg process has exited unexpectedly. In this case I guess the fix you have is appropriate defensive programming, causing the test to fail when this happens, but still won't explain why it happens and also won't prevent future failures of this test. Also, this type of Debuggee early exit problem could happen with other tests too. I'm leaning towards just closing this bug as CNR. I don't think we want to be writing our tests to defend against random system related failures, especially when the end result is still going to be a test failure that we don't fully understand. thanks, Chris On 9/5/18 7:33 AM, Gary Adams wrote: > The DebuggerThreadTest ensures it is in sync > at the beginning of RunTests with a breakpoint event > in DebuggerThreadTarg ready() method. > > The DebuggerThreadTest then continues with > dumpThreads() and listenUntilVMDisconnect() > completes. > > If the DebugThreadTarg is resumed prematurely, > the main thread in the debuggee could complete > before the dumpThreads enumeration is complete. > > DebuggerThreadTest > ? main() > ??? startTests() > ?????? runTests() > ????????? startTo( "DebuggerThreadTarg.ready()") > ????????? dumpThreads() > ????????? listenUntilVMDisconnect() > > DebuggerThreadTarg > ? main() > ???? ready() > > Revised fix: > ? - Prevents the NPE from a finished thread group > ? - Fails the test with a message indicating > ???? number of premature completed threads. > > diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java > b/test/jdk/com/sun/jdi/DebuggerThreadTest.java > --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java > +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -76,8 +76,16 @@ > ???????? Thread list[] = new Thread[listThreads * 2]; > ???????? int gotThreads = tg.enumerate(list, true); > ???????? for (int i = 0; i < Math.min(gotThreads, list.length); i++){ > +??????????? int finishedThreads = 0; > ???????????? Thread t = list[i]; > -??????????? String groupName = t.getThreadGroup().getName(); > +??????????? ThreadGroup tga = t.getThreadGroup(); > +??????????? String groupName; > +??????????? if (tga == null) { > +??????????????? groupName = ""; > +??????????????? finishedThreads++ ; > +??????????? } else { > +??????????????? groupName =tga.getName(); > +??????????? } > > ???????????? System.out.println("Thread [" + i + "] group = '" + > ??????????????????????????????? groupName + > @@ -89,7 +97,10 @@ > ???????????????? failure("FAIL: non-daemon thread '" + t.getName() + > ???????????????????????? "' found in ThreadGroup '" + groupName + "'"); > ???????????? } > - > +??????????? if (finishedThreads > 0 ) { > +??????????????? failure("FAIL: " + finishedThreads + > +??????????????????????? " threads completed while VM suspended."); > +??????????? } > ???????? } > ???? } > > > On 9/4/18, 3:15 PM, Chris Plummer wrote: >> Hi Gary, >> >> The failed case only had: >> >> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >> Thread [1] group = 'system' name = 'Finalizer' daemon = true >> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >> Thread [3] group = 'system' name = 'process reaper' daemon = true >> >> That would indicate that 'main' is likely the thread that exited. >> Seems odd. Isn't that the thread that the test is executing in? >> >> If you can't reproduce it, maybe it would be better to commit a >> diagnostic fix like the one I suggested and keep an eye on it. >> However, it only seems to have failed once due to this reason, so >> unless it is a new problem we may never see it again. >> >> Chris >> >> On 9/4/18 11:28 AM, Gary Adams wrote: >>> I haven't been able to reproduce the problem locally. >>> Trying larger test runs on mach5 now. >>> >>> Here's the output from a successful test run. >>> If any of the threads exited, they would have a null group name. >>> >>> Howdy! >>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>> Thread [4] group = 'main' name = 'main' daemon = false >>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>> daemon = false >>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>> daemon = false >>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>> daemon = false >>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon = true >>> Thread [10] group = 'InnocuousThreadGroup' name = 'Common-Cleaner' >>> daemon = true >>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event >>> Handler' daemon = true >>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>> Interface' daemon = true >>> Goodbye from DebuggerThreadTarg! >>> >>> >>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>> Can you reproduce the problem? If so, maybe to find out which >>>> thread is a problem you could check for null, print the thread >>>> info, and then fail the test. >>>> >>>> Chris >>>> >>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>> I'm not sure which thread exited causes the NPE. >>>>> This patch will let? the test continue and at least >>>>> let the list of threads be processed. >>>>> >>>>> The test walks up the parents to the initial thread >>>>> and then "enumerates()" the set of the threads to check. >>>>> There is an inherent race condition in enumerate() >>>>> that recognizes it is a snapshot of a moving target. >>>>> >>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>> Hi Gary, >>>>>> >>>>>> Why has the thread exited if the debuggee is still running? >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() >>>>>>> which could be null >>>>>>> if the thread has terminated. >>>>>>> >>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>> >>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> @@ -77,7 +77,8 @@ >>>>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>>>> ???????? for (int i = 0; i < Math.min(gotThreads, list.length); >>>>>>> i++){ >>>>>>> ???????????? Thread t = list[i]; >>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>> + String groupName = (tga == null ? "": tga.getName()); >>>>>>> >>>>>>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>>>>>> ??????????????????????????????? groupName + >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From jcbeyler at google.com Wed Sep 5 18:14:37 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 5 Sep 2018 11:14:37 -0700 Subject: RFR (S) 8208352: Merge HeapMonitorTest and HeapMonitorGCTest code Message-ID: Hi all, Two of the tests shared code and we could refactor to limit future fixes/changes in both spots. Here is the small webrev that does that: Webrev: http://cr.openjdk.java.net/~jcbeyler/8208352/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8208352 Thank you for the future reviews, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Sep 5 18:26:11 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 05 Sep 2018 14:26:11 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> Message-ID: <5B901FC3.6080904@oracle.com> If we go ahead with this proposed fix, the next time it fails we will have more information about the other threads captured in the log. One last observation, the test that failed was running with UseZGC. Not sure how that might impact this particular test. On 9/5/18, 2:07 PM, Chris Plummer wrote: > > Hi Gary, > >> If the DebugThreadTarg is resumed prematurely, > > The failure explanation seems to hinge on this, but I don't see how > this can happen. What is resuming DebugThreadTarg? Only the call to > listenUntilVMDisconnect() should be doing this, and we aren't even > getting that far. The only thing I can think of is due to some other > issue (maybe host out of memory so process was killed off), the > DebugThreadTarg process has exited unexpectedly. In this case I guess > the fix you have is appropriate defensive programming, causing the > test to fail when this happens, but still won't explain why it happens > and also won't prevent future failures of this test. Also, this type > of Debuggee early exit problem could happen with other tests too. I'm > leaning towards just closing this bug as CNR. I don't think we want to > be writing our tests to defend against random system related failures, > especially when the end result is still going to be a test failure > that we don't fully understand. > > thanks, > > Chris > > On 9/5/18 7:33 AM, Gary Adams wrote: >> The DebuggerThreadTest ensures it is in sync >> at the beginning of RunTests with a breakpoint event >> in DebuggerThreadTarg ready() method. >> >> The DebuggerThreadTest then continues with >> dumpThreads() and listenUntilVMDisconnect() >> completes. >> >> If the DebugThreadTarg is resumed prematurely, >> the main thread in the debuggee could complete >> before the dumpThreads enumeration is complete. >> >> DebuggerThreadTest >> main() >> startTests() >> runTests() >> startTo( "DebuggerThreadTarg.ready()") >> dumpThreads() >> listenUntilVMDisconnect() >> >> DebuggerThreadTarg >> main() >> ready() >> >> Revised fix: >> - Prevents the NPE from a finished thread group >> - Fails the test with a message indicating >> number of premature completed threads. >> >> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -76,8 +76,16 @@ >> Thread list[] = new Thread[listThreads * 2]; >> int gotThreads = tg.enumerate(list, true); >> for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >> + int finishedThreads = 0; >> Thread t = list[i]; >> - String groupName = t.getThreadGroup().getName(); >> + ThreadGroup tga = t.getThreadGroup(); >> + String groupName; >> + if (tga == null) { >> + groupName = ""; >> + finishedThreads++ ; >> + } else { >> + groupName =tga.getName(); >> + } >> >> System.out.println("Thread [" + i + "] group = '" + >> groupName + >> @@ -89,7 +97,10 @@ >> failure("FAIL: non-daemon thread '" + t.getName() + >> "' found in ThreadGroup '" + groupName + "'"); >> } >> - >> + if (finishedThreads > 0 ) { >> + failure("FAIL: " + finishedThreads + >> + " threads completed while VM suspended."); >> + } >> } >> } >> >> >> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> The failed case only had: >>> >>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>> >>> That would indicate that 'main' is likely the thread that exited. >>> Seems odd. Isn't that the thread that the test is executing in? >>> >>> If you can't reproduce it, maybe it would be better to commit a >>> diagnostic fix like the one I suggested and keep an eye on it. >>> However, it only seems to have failed once due to this reason, so >>> unless it is a new problem we may never see it again. >>> >>> Chris >>> >>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>> I haven't been able to reproduce the problem locally. >>>> Trying larger test runs on mach5 now. >>>> >>>> Here's the output from a successful test run. >>>> If any of the threads exited, they would have a null group name. >>>> >>>> Howdy! >>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>> Thread [4] group = 'main' name = 'main' daemon = false >>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>>> daemon = false >>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>>> daemon = false >>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>>> daemon = false >>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon = >>>> true >>>> Thread [10] group = 'InnocuousThreadGroup' name = 'Common-Cleaner' >>>> daemon = true >>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event >>>> Handler' daemon = true >>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>> Interface' daemon = true >>>> Goodbye from DebuggerThreadTarg! >>>> >>>> >>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>> Can you reproduce the problem? If so, maybe to find out which >>>>> thread is a problem you could check for null, print the thread >>>>> info, and then fail the test. >>>>> >>>>> Chris >>>>> >>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>> I'm not sure which thread exited causes the NPE. >>>>>> This patch will let the test continue and at least >>>>>> let the list of threads be processed. >>>>>> >>>>>> The test walks up the parents to the initial thread >>>>>> and then "enumerates()" the set of the threads to check. >>>>>> There is an inherent race condition in enumerate() >>>>>> that recognizes it is a snapshot of a moving target. >>>>>> >>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() >>>>>>>> which could be null >>>>>>>> if the thread has terminated. >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>> >>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>>> for (int i = 0; i < Math.min(gotThreads, list.length); >>>>>>>> i++){ >>>>>>>> Thread t = list[i]; >>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>> + String groupName = (tga == null ? "": tga.getName()); >>>>>>>> >>>>>>>> System.out.println("Thread [" + i + "] group = '" + >>>>>>>> groupName + >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From chris.plummer at oracle.com Wed Sep 5 18:31:12 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 11:31:12 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B901FC3.6080904@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> Message-ID: <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> Ok. Have you found a way to test your changes? Maybe just force or simulate a failure somehow. Chris On 9/5/18 11:26 AM, Gary Adams wrote: > If we go ahead with this proposed fix, the next time it fails > we will have more information about the other threads > captured in the log. > > One last observation, the test that failed was running with UseZGC. > Not sure how that might impact this particular test. > > On 9/5/18, 2:07 PM, Chris Plummer wrote: >> >> Hi Gary, >> >>> If the DebugThreadTarg is resumed prematurely, >> >> The failure explanation seems to hinge on this, but I don't see how >> this can happen. What is resuming DebugThreadTarg? Only the call to >> listenUntilVMDisconnect() should be doing this, and we aren't even >> getting that far. The only thing I can think of is due to some other >> issue (maybe host out of memory so process was killed off), the >> DebugThreadTarg process has exited unexpectedly. In this case I guess >> the fix you have is appropriate defensive programming, causing the >> test to fail when this happens, but still won't explain why it >> happens and also won't prevent future failures of this test. Also, >> this type of Debuggee early exit problem could happen with other >> tests too. I'm leaning towards just closing this bug as CNR. I don't >> think we want to be writing our tests to defend against random system >> related failures, especially when the end result is still going to be >> a test failure that we don't fully understand. >> >> thanks, >> >> Chris >> >> On 9/5/18 7:33 AM, Gary Adams wrote: >>> The DebuggerThreadTest ensures it is in sync >>> at the beginning of RunTests with a breakpoint event >>> in DebuggerThreadTarg ready() method. >>> >>> The DebuggerThreadTest then continues with >>> dumpThreads() and listenUntilVMDisconnect() >>> completes. >>> >>> If the DebugThreadTarg is resumed prematurely, >>> the main thread in the debuggee could complete >>> before the dumpThreads enumeration is complete. >>> >>> DebuggerThreadTest >>> ? main() >>> ??? startTests() >>> ?????? runTests() >>> ????????? startTo( "DebuggerThreadTarg.ready()") >>> ????????? dumpThreads() >>> ????????? listenUntilVMDisconnect() >>> >>> DebuggerThreadTarg >>> ? main() >>> ???? ready() >>> >>> Revised fix: >>> ? - Prevents the NPE from a finished thread group >>> ? - Fails the test with a message indicating >>> ???? number of premature completed threads. >>> >>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>> @@ -1,5 +1,5 @@ >>> ?/* >>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ? * >>> ? * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -76,8 +76,16 @@ >>> ???????? Thread list[] = new Thread[listThreads * 2]; >>> ???????? int gotThreads = tg.enumerate(list, true); >>> ???????? for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >>> +??????????? int finishedThreads = 0; >>> ???????????? Thread t = list[i]; >>> -??????????? String groupName = t.getThreadGroup().getName(); >>> +??????????? ThreadGroup tga = t.getThreadGroup(); >>> +??????????? String groupName; >>> +??????????? if (tga == null) { >>> +??????????????? groupName = ""; >>> +??????????????? finishedThreads++ ; >>> +??????????? } else { >>> +??????????????? groupName =tga.getName(); >>> +??????????? } >>> >>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>> ??????????????????????????????? groupName + >>> @@ -89,7 +97,10 @@ >>> ???????????????? failure("FAIL: non-daemon thread '" + t.getName() + >>> ???????????????????????? "' found in ThreadGroup '" + groupName + "'"); >>> ???????????? } >>> - >>> +??????????? if (finishedThreads > 0 ) { >>> +??????????????? failure("FAIL: " + finishedThreads + >>> +??????????????????????? " threads completed while VM suspended."); >>> +??????????? } >>> ???????? } >>> ???? } >>> >>> >>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> The failed case only had: >>>> >>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>> >>>> That would indicate that 'main' is likely the thread that exited. >>>> Seems odd. Isn't that the thread that the test is executing in? >>>> >>>> If you can't reproduce it, maybe it would be better to commit a >>>> diagnostic fix like the one I suggested and keep an eye on it. >>>> However, it only seems to have failed once due to this reason, so >>>> unless it is a new problem we may never see it again. >>>> >>>> Chris >>>> >>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>> I haven't been able to reproduce the problem locally. >>>>> Trying larger test runs on mach5 now. >>>>> >>>>> Here's the output from a successful test run. >>>>> If any of the threads exited, they would have a null group name. >>>>> >>>>> Howdy! >>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>>>> daemon = false >>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>>>> daemon = false >>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>>>> daemon = false >>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon = >>>>> true >>>>> Thread [10] group = 'InnocuousThreadGroup' name = 'Common-Cleaner' >>>>> daemon = true >>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event >>>>> Handler' daemon = true >>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>> Interface' daemon = true >>>>> Goodbye from DebuggerThreadTarg! >>>>> >>>>> >>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>> Can you reproduce the problem? If so, maybe to find out which >>>>>> thread is a problem you could check for null, print the thread >>>>>> info, and then fail the test. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>> This patch will let? the test continue and at least >>>>>>> let the list of threads be processed. >>>>>>> >>>>>>> The test walks up the parents to the initial thread >>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>> There is an inherent race condition in enumerate() >>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>> >>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() >>>>>>>>> which could be null >>>>>>>>> if the thread has terminated. >>>>>>>>> >>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>> >>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>>>>>> ???????? for (int i = 0; i < Math.min(gotThreads, >>>>>>>>> list.length); i++){ >>>>>>>>> ???????????? Thread t = list[i]; >>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>> tga.getName()); >>>>>>>>> >>>>>>>>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>>>>>>>> ??????????????????????????????? groupName + >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From gary.adams at oracle.com Wed Sep 5 18:49:01 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 05 Sep 2018 14:49:01 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> Message-ID: <5B90251D.600@oracle.com> I had tried sleeping after each entry in dumpThreads was checked, but the failure never occurred. I had tried using mach5 --jvm-args to set UseZGC, but that never failed. Could attempt a resume() before calling dumpThreads() - haven't tried that , yet. On 9/5/18, 2:31 PM, Chris Plummer wrote: > Ok. Have you found a way to test your changes? Maybe just force or > simulate a failure somehow. > > Chris > > On 9/5/18 11:26 AM, Gary Adams wrote: >> If we go ahead with this proposed fix, the next time it fails >> we will have more information about the other threads >> captured in the log. >> >> One last observation, the test that failed was running with UseZGC. >> Not sure how that might impact this particular test. >> >> On 9/5/18, 2:07 PM, Chris Plummer wrote: >>> >>> Hi Gary, >>> >>>> If the DebugThreadTarg is resumed prematurely, >>> >>> The failure explanation seems to hinge on this, but I don't see how >>> this can happen. What is resuming DebugThreadTarg? Only the call to >>> listenUntilVMDisconnect() should be doing this, and we aren't even >>> getting that far. The only thing I can think of is due to some other >>> issue (maybe host out of memory so process was killed off), the >>> DebugThreadTarg process has exited unexpectedly. In this case I >>> guess the fix you have is appropriate defensive programming, causing >>> the test to fail when this happens, but still won't explain why it >>> happens and also won't prevent future failures of this test. Also, >>> this type of Debuggee early exit problem could happen with other >>> tests too. I'm leaning towards just closing this bug as CNR. I don't >>> think we want to be writing our tests to defend against random >>> system related failures, especially when the end result is still >>> going to be a test failure that we don't fully understand. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/5/18 7:33 AM, Gary Adams wrote: >>>> The DebuggerThreadTest ensures it is in sync >>>> at the beginning of RunTests with a breakpoint event >>>> in DebuggerThreadTarg ready() method. >>>> >>>> The DebuggerThreadTest then continues with >>>> dumpThreads() and listenUntilVMDisconnect() >>>> completes. >>>> >>>> If the DebugThreadTarg is resumed prematurely, >>>> the main thread in the debuggee could complete >>>> before the dumpThreads enumeration is complete. >>>> >>>> DebuggerThreadTest >>>> main() >>>> startTests() >>>> runTests() >>>> startTo( "DebuggerThreadTarg.ready()") >>>> dumpThreads() >>>> listenUntilVMDisconnect() >>>> >>>> DebuggerThreadTarg >>>> main() >>>> ready() >>>> >>>> Revised fix: >>>> - Prevents the NPE from a finished thread group >>>> - Fails the test with a message indicating >>>> number of premature completed threads. >>>> >>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -76,8 +76,16 @@ >>>> Thread list[] = new Thread[listThreads * 2]; >>>> int gotThreads = tg.enumerate(list, true); >>>> for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >>>> + int finishedThreads = 0; >>>> Thread t = list[i]; >>>> - String groupName = t.getThreadGroup().getName(); >>>> + ThreadGroup tga = t.getThreadGroup(); >>>> + String groupName; >>>> + if (tga == null) { >>>> + groupName = ""; >>>> + finishedThreads++ ; >>>> + } else { >>>> + groupName =tga.getName(); >>>> + } >>>> >>>> System.out.println("Thread [" + i + "] group = '" + >>>> groupName + >>>> @@ -89,7 +97,10 @@ >>>> failure("FAIL: non-daemon thread '" + t.getName() + >>>> "' found in ThreadGroup '" + groupName + >>>> "'"); >>>> } >>>> - >>>> + if (finishedThreads > 0 ) { >>>> + failure("FAIL: " + finishedThreads + >>>> + " threads completed while VM suspended."); >>>> + } >>>> } >>>> } >>>> >>>> >>>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> The failed case only had: >>>>> >>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>> >>>>> That would indicate that 'main' is likely the thread that exited. >>>>> Seems odd. Isn't that the thread that the test is executing in? >>>>> >>>>> If you can't reproduce it, maybe it would be better to commit a >>>>> diagnostic fix like the one I suggested and keep an eye on it. >>>>> However, it only seems to have failed once due to this reason, so >>>>> unless it is a new problem we may never see it again. >>>>> >>>>> Chris >>>>> >>>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>>> I haven't been able to reproduce the problem locally. >>>>>> Trying larger test runs on mach5 now. >>>>>> >>>>>> Here's the output from a successful test run. >>>>>> If any of the threads exited, they would have a null group name. >>>>>> >>>>>> Howdy! >>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>>>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>>>>> daemon = false >>>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>> daemon = false >>>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>> daemon = false >>>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon >>>>>> = true >>>>>> Thread [10] group = 'InnocuousThreadGroup' name = >>>>>> 'Common-Cleaner' daemon = true >>>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal Event >>>>>> Handler' daemon = true >>>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>>> Interface' daemon = true >>>>>> Goodbye from DebuggerThreadTarg! >>>>>> >>>>>> >>>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>>> Can you reproduce the problem? If so, maybe to find out which >>>>>>> thread is a problem you could check for null, print the thread >>>>>>> info, and then fail the test. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>>> This patch will let the test continue and at least >>>>>>>> let the list of threads be processed. >>>>>>>> >>>>>>>> The test walks up the parents to the initial thread >>>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>>> There is an inherent race condition in enumerate() >>>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>>> >>>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() >>>>>>>>>> which could be null >>>>>>>>>> if the thread has terminated. >>>>>>>>>> >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>>> >>>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>>>>> for (int i = 0; i < Math.min(gotThreads, >>>>>>>>>> list.length); i++){ >>>>>>>>>> Thread t = list[i]; >>>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>>> tga.getName()); >>>>>>>>>> >>>>>>>>>> System.out.println("Thread [" + i + "] group = '" + >>>>>>>>>> groupName + >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From chris.plummer at oracle.com Wed Sep 5 18:56:06 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 11:56:06 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B90251D.600@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> <5B90251D.600@oracle.com> Message-ID: <91580473-07d0-84bf-18c5-3e92b38b00cd@oracle.com> I was thinking something like the resume() call. At the very least just try setting finishedThreads = 1 to exercise the error handling. Chris ?On 9/5/18 11:49 AM, Gary Adams wrote: > I had tried sleeping after each entry in dumpThreads was checked, but the > failure never occurred. > > I had tried using mach5 --jvm-args to set UseZGC, but that never failed. > > Could attempt a resume() before calling dumpThreads() - haven't tried > that , yet. > > On 9/5/18, 2:31 PM, Chris Plummer wrote: >> Ok. Have you found a way to test your changes? Maybe just force or >> simulate a failure somehow. >> >> Chris >> >> On 9/5/18 11:26 AM, Gary Adams wrote: >>> If we go ahead with this proposed fix, the next time it fails >>> we will have more information about the other threads >>> captured in the log. >>> >>> One last observation, the test that failed was running with UseZGC. >>> Not sure how that might impact this particular test. >>> >>> On 9/5/18, 2:07 PM, Chris Plummer wrote: >>>> >>>> Hi Gary, >>>> >>>>> If the DebugThreadTarg is resumed prematurely, >>>> >>>> The failure explanation seems to hinge on this, but I don't see how >>>> this can happen. What is resuming DebugThreadTarg? Only the call to >>>> listenUntilVMDisconnect() should be doing this, and we aren't even >>>> getting that far. The only thing I can think of is due to some >>>> other issue (maybe host out of memory so process was killed off), >>>> the DebugThreadTarg process has exited unexpectedly. In this case I >>>> guess the fix you have is appropriate defensive programming, >>>> causing the test to fail when this happens, but still won't explain >>>> why it happens and also won't prevent future failures of this test. >>>> Also, this type of Debuggee early exit problem could happen with >>>> other tests too. I'm leaning towards just closing this bug as CNR. >>>> I don't think we want to be writing our tests to defend against >>>> random system related failures, especially when the end result is >>>> still going to be a test failure that we don't fully understand. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 9/5/18 7:33 AM, Gary Adams wrote: >>>>> The DebuggerThreadTest ensures it is in sync >>>>> at the beginning of RunTests with a breakpoint event >>>>> in DebuggerThreadTarg ready() method. >>>>> >>>>> The DebuggerThreadTest then continues with >>>>> dumpThreads() and listenUntilVMDisconnect() >>>>> completes. >>>>> >>>>> If the DebugThreadTarg is resumed prematurely, >>>>> the main thread in the debuggee could complete >>>>> before the dumpThreads enumeration is complete. >>>>> >>>>> DebuggerThreadTest >>>>> ? main() >>>>> ??? startTests() >>>>> ?????? runTests() >>>>> ????????? startTo( "DebuggerThreadTarg.ready()") >>>>> ????????? dumpThreads() >>>>> ????????? listenUntilVMDisconnect() >>>>> >>>>> DebuggerThreadTarg >>>>> ? main() >>>>> ???? ready() >>>>> >>>>> Revised fix: >>>>> ? - Prevents the NPE from a finished thread group >>>>> ? - Fails the test with a message indicating >>>>> ???? number of premature completed threads. >>>>> >>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>> @@ -1,5 +1,5 @@ >>>>> ?/* >>>>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> ? * >>>>> ? * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> @@ -76,8 +76,16 @@ >>>>> ???????? Thread list[] = new Thread[listThreads * 2]; >>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>> ???????? for (int i = 0; i < Math.min(gotThreads, list.length); i++){ >>>>> +??????????? int finishedThreads = 0; >>>>> ???????????? Thread t = list[i]; >>>>> -??????????? String groupName = t.getThreadGroup().getName(); >>>>> +??????????? ThreadGroup tga = t.getThreadGroup(); >>>>> +??????????? String groupName; >>>>> +??????????? if (tga == null) { >>>>> +??????????????? groupName = ""; >>>>> +??????????????? finishedThreads++ ; >>>>> +??????????? } else { >>>>> +??????????????? groupName =tga.getName(); >>>>> +??????????? } >>>>> >>>>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>>>> ??????????????????????????????? groupName + >>>>> @@ -89,7 +97,10 @@ >>>>> ???????????????? failure("FAIL: non-daemon thread '" + t.getName() + >>>>> ???????????????????????? "' found in ThreadGroup '" + groupName + >>>>> "'"); >>>>> ???????????? } >>>>> - >>>>> +??????????? if (finishedThreads > 0 ) { >>>>> +??????????????? failure("FAIL: " + finishedThreads + >>>>> +??????????????????????? " threads completed while VM suspended."); >>>>> +??????????? } >>>>> ???????? } >>>>> ???? } >>>>> >>>>> >>>>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>>>> Hi Gary, >>>>>> >>>>>> The failed case only had: >>>>>> >>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = true >>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = true >>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>> >>>>>> That would indicate that 'main' is likely the thread that exited. >>>>>> Seems odd. Isn't that the thread that the test is executing in? >>>>>> >>>>>> If you can't reproduce it, maybe it would be better to commit a >>>>>> diagnostic fix like the one I suggested and keep an eye on it. >>>>>> However, it only seems to have failed once due to this reason, so >>>>>> unless it is a new problem we may never see it again. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>>>> I haven't been able to reproduce the problem locally. >>>>>>> Trying larger test runs on mach5 now. >>>>>>> >>>>>>> Here's the output from a successful test run. >>>>>>> If any of the threads exited, they would have a null group name. >>>>>>> >>>>>>> Howdy! >>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = >>>>>>> true >>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = >>>>>>> true >>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>>>>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>>>>>> daemon = false >>>>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>>> daemon = false >>>>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>>> daemon = false >>>>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' daemon >>>>>>> = true >>>>>>> Thread [10] group = 'InnocuousThreadGroup' name = >>>>>>> 'Common-Cleaner' daemon = true >>>>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal >>>>>>> Event Handler' daemon = true >>>>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>>>> Interface' daemon = true >>>>>>> Goodbye from DebuggerThreadTarg! >>>>>>> >>>>>>> >>>>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>>>> Can you reproduce the problem? If so, maybe to find out which >>>>>>>> thread is a problem you could check for null, print the thread >>>>>>>> info, and then fail the test. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>>>> This patch will let? the test continue and at least >>>>>>>>> let the list of threads be processed. >>>>>>>>> >>>>>>>>> The test walks up the parents to the initial thread >>>>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>>>> There is an inherent race condition in enumerate() >>>>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>>>> >>>>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>>>> Hi Gary, >>>>>>>>>> >>>>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>>>> Here's a quick fix to avoid the NPE using a getThreadGroup() >>>>>>>>>>> which could be null >>>>>>>>>>> if the thread has terminated. >>>>>>>>>>> >>>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>>>> >>>>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>>>>>>>> ???????? for (int i = 0; i < Math.min(gotThreads, >>>>>>>>>>> list.length); i++){ >>>>>>>>>>> ???????????? Thread t = list[i]; >>>>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>>>> tga.getName()); >>>>>>>>>>> >>>>>>>>>>> ???????????? System.out.println("Thread [" + i + "] group = >>>>>>>>>>> '" + >>>>>>>>>>> ??????????????????????????????? groupName + >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From chris.plummer at oracle.com Wed Sep 5 18:59:10 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 11:59:10 -0700 Subject: RFR (S) 8208352: Merge HeapMonitorTest and HeapMonitorGCTest code In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Sep 5 19:14:16 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 5 Sep 2018 12:14:16 -0700 Subject: RFR (M) 8210198: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[A-F] tests In-Reply-To: References: Message-ID: +1 --alex On 09/04/2018 17:10, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > It looks good to me. > Thank you for this cleanup! > > Thanks, > Serguei > > > On 9/4/18 16:12, JC Beyler wrote: >> Hi all, >> >> Continuing the removal of the JNI_ENV* macros, I have done about half >> of the JVMTI Get[A-F] methods. The whole change for jvmti/GetXX tests >> was about 2k of changes so it seemed best to just divide it into two >> parts (from my approximation there will be 2 more webrevs to finish >> the umbrella item JDK-8209547). >> >> The change is straightforward as before, just a bit repetitive: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210198/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210198 >> >> I tested this in release mode for the tests that were modified. >> >> Thanks, >> Jc > From gary.adams at oracle.com Wed Sep 5 19:16:00 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 05 Sep 2018 15:16:00 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <91580473-07d0-84bf-18c5-3e92b38b00cd@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> <5B90251D.600@oracle.com> <91580473-07d0-84bf-18c5-3e92b38b00cd@oracle.com> Message-ID: <5B902B70.8080700@oracle.com> After a quick local check of finishedThreads =1, I moved the check til after the full list of threads is checked, rather than repeating the stderr failure after each entry was processed. I also implemented a resumeVM() in TestScaffold and called it before dumpThreads(). That did not fail locally, so I submitted a mach5 job so I can run more tests in batches. ... On 9/5/18, 2:56 PM, Chris Plummer wrote: > I was thinking something like the resume() call. At the very least > just try setting finishedThreads = 1 to exercise the error handling. > > Chris > > On 9/5/18 11:49 AM, Gary Adams wrote: >> I had tried sleeping after each entry in dumpThreads was checked, but >> the >> failure never occurred. >> >> I had tried using mach5 --jvm-args to set UseZGC, but that never failed. >> >> Could attempt a resume() before calling dumpThreads() - haven't tried >> that , yet. >> >> On 9/5/18, 2:31 PM, Chris Plummer wrote: >>> Ok. Have you found a way to test your changes? Maybe just force or >>> simulate a failure somehow. >>> >>> Chris >>> >>> On 9/5/18 11:26 AM, Gary Adams wrote: >>>> If we go ahead with this proposed fix, the next time it fails >>>> we will have more information about the other threads >>>> captured in the log. >>>> >>>> One last observation, the test that failed was running with UseZGC. >>>> Not sure how that might impact this particular test. >>>> >>>> On 9/5/18, 2:07 PM, Chris Plummer wrote: >>>>> >>>>> Hi Gary, >>>>> >>>>>> If the DebugThreadTarg is resumed prematurely, >>>>> >>>>> The failure explanation seems to hinge on this, but I don't see >>>>> how this can happen. What is resuming DebugThreadTarg? Only the >>>>> call to listenUntilVMDisconnect() should be doing this, and we >>>>> aren't even getting that far. The only thing I can think of is due >>>>> to some other issue (maybe host out of memory so process was >>>>> killed off), the DebugThreadTarg process has exited unexpectedly. >>>>> In this case I guess the fix you have is appropriate defensive >>>>> programming, causing the test to fail when this happens, but still >>>>> won't explain why it happens and also won't prevent future >>>>> failures of this test. Also, this type of Debuggee early exit >>>>> problem could happen with other tests too. I'm leaning towards >>>>> just closing this bug as CNR. I don't think we want to be writing >>>>> our tests to defend against random system related failures, >>>>> especially when the end result is still going to be a test failure >>>>> that we don't fully understand. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 9/5/18 7:33 AM, Gary Adams wrote: >>>>>> The DebuggerThreadTest ensures it is in sync >>>>>> at the beginning of RunTests with a breakpoint event >>>>>> in DebuggerThreadTarg ready() method. >>>>>> >>>>>> The DebuggerThreadTest then continues with >>>>>> dumpThreads() and listenUntilVMDisconnect() >>>>>> completes. >>>>>> >>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>> the main thread in the debuggee could complete >>>>>> before the dumpThreads enumeration is complete. >>>>>> >>>>>> DebuggerThreadTest >>>>>> main() >>>>>> startTests() >>>>>> runTests() >>>>>> startTo( "DebuggerThreadTarg.ready()") >>>>>> dumpThreads() >>>>>> listenUntilVMDisconnect() >>>>>> >>>>>> DebuggerThreadTarg >>>>>> main() >>>>>> ready() >>>>>> >>>>>> Revised fix: >>>>>> - Prevents the NPE from a finished thread group >>>>>> - Fails the test with a message indicating >>>>>> number of premature completed threads. >>>>>> >>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>> @@ -1,5 +1,5 @@ >>>>>> /* >>>>>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>> * >>>>>> * This code is free software; you can redistribute it and/or >>>>>> modify it >>>>>> @@ -76,8 +76,16 @@ >>>>>> Thread list[] = new Thread[listThreads * 2]; >>>>>> int gotThreads = tg.enumerate(list, true); >>>>>> for (int i = 0; i < Math.min(gotThreads, list.length); >>>>>> i++){ >>>>>> + int finishedThreads = 0; >>>>>> Thread t = list[i]; >>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>> + String groupName; >>>>>> + if (tga == null) { >>>>>> + groupName = ""; >>>>>> + finishedThreads++ ; >>>>>> + } else { >>>>>> + groupName =tga.getName(); >>>>>> + } >>>>>> >>>>>> System.out.println("Thread [" + i + "] group = '" + >>>>>> groupName + >>>>>> @@ -89,7 +97,10 @@ >>>>>> failure("FAIL: non-daemon thread '" + t.getName() + >>>>>> "' found in ThreadGroup '" + groupName + >>>>>> "'"); >>>>>> } >>>>>> - >>>>>> + if (finishedThreads > 0 ) { >>>>>> + failure("FAIL: " + finishedThreads + >>>>>> + " threads completed while VM suspended."); >>>>>> + } >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> The failed case only had: >>>>>>> >>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = >>>>>>> true >>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = >>>>>>> true >>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>>> >>>>>>> That would indicate that 'main' is likely the thread that >>>>>>> exited. Seems odd. Isn't that the thread that the test is >>>>>>> executing in? >>>>>>> >>>>>>> If you can't reproduce it, maybe it would be better to commit a >>>>>>> diagnostic fix like the one I suggested and keep an eye on it. >>>>>>> However, it only seems to have failed once due to this reason, >>>>>>> so unless it is a new problem we may never see it again. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>>>>> I haven't been able to reproduce the problem locally. >>>>>>>> Trying larger test runs on mach5 now. >>>>>>>> >>>>>>>> Here's the output from a successful test run. >>>>>>>> If any of the threads exited, they would have a null group name. >>>>>>>> >>>>>>>> Howdy! >>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = >>>>>>>> true >>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = >>>>>>>> true >>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>>>>>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>>>>>>> daemon = false >>>>>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>>>> daemon = false >>>>>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>>>> daemon = false >>>>>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' >>>>>>>> daemon = true >>>>>>>> Thread [10] group = 'InnocuousThreadGroup' name = >>>>>>>> 'Common-Cleaner' daemon = true >>>>>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal >>>>>>>> Event Handler' daemon = true >>>>>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>>>>> Interface' daemon = true >>>>>>>> Goodbye from DebuggerThreadTarg! >>>>>>>> >>>>>>>> >>>>>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>>>>> Can you reproduce the problem? If so, maybe to find out which >>>>>>>>> thread is a problem you could check for null, print the thread >>>>>>>>> info, and then fail the test. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>>>>> This patch will let the test continue and at least >>>>>>>>>> let the list of threads be processed. >>>>>>>>>> >>>>>>>>>> The test walks up the parents to the initial thread >>>>>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>>>>> There is an inherent race condition in enumerate() >>>>>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>>>>> >>>>>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>>>>> Hi Gary, >>>>>>>>>>> >>>>>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>>>>> Here's a quick fix to avoid the NPE using a >>>>>>>>>>>> getThreadGroup() which could be null >>>>>>>>>>>> if the thread has terminated. >>>>>>>>>>>> >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>>>>>>> for (int i = 0; i < Math.min(gotThreads, >>>>>>>>>>>> list.length); i++){ >>>>>>>>>>>> Thread t = list[i]; >>>>>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>>>>> tga.getName()); >>>>>>>>>>>> >>>>>>>>>>>> System.out.println("Thread [" + i + "] group = >>>>>>>>>>>> '" + >>>>>>>>>>>> groupName + >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From chris.plummer at oracle.com Wed Sep 5 19:17:51 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 12:17:51 -0700 Subject: RFR (M) 8210198: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[A-F] tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Sep 5 19:32:01 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 5 Sep 2018 12:32:01 -0700 Subject: RFR (S) 8208352: Merge HeapMonitorTest and HeapMonitorGCTest code In-Reply-To: References: Message-ID: <003536af-7a99-2886-37d8-ae80863b82a7@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 5 19:37:03 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 5 Sep 2018 12:37:03 -0700 Subject: RFR (M) 8210198: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[A-F] tests In-Reply-To: References: Message-ID: Hi Chris, I had seen that formatting in bytecodes001.cpp but was not sure it made the line a bit too long (I think there is no real line wrap limit, just what seems reasonable, correct?). But done since you saw it too, that makes two of us wanting to change it! I changed all the IsSameObject != JNI_TRUE in the files I changed and added it to my refactoring logic for the next round of refactoring. Here is the new webrev with the metadata if you wanted to see it (I was not sure if you wanted to see it again): Webrev: http://cr.openjdk.java.net/~jcbeyler/8210198/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210198 I double checked testing and it passes again all tests changed on my linux dev machine. Thanks again, Jc On Wed, Sep 5, 2018 at 12:18 PM Chris Plummer wrote: > Hi JC, > > In bytecodes001.cpp the formatting could use some improvement: > > 130 if (meth_tab[meth_ind].stat == JNI_TRUE) { > 131 mid = env->GetStaticMethodID(cl, > 132 meth_tab[meth_ind].name, meth_tab[meth_ind].sig); > 133 } else { > 134 mid = env->GetMethodID(cl, > 135 meth_tab[meth_ind].name, meth_tab[meth_ind].sig); > 136 } > > In getclsldr003.cpp, getfldecl001.cpp, getfldecl002.cpp, and > getfldecl004.cpp, no need to compare with JNI_TRUE. Just negate the > expression.: > > 98 if (env->IsSameObject(classloader, cl) != JNI_TRUE) { > > Otherwise looks good. > > Thanks for the cleanup, > > Chris > > On 9/4/18 4:12 PM, JC Beyler wrote: > > Hi all, > > Continuing the removal of the JNI_ENV* macros, I have done about half of > the JVMTI Get[A-F] methods. The whole change for jvmti/GetXX tests was > about 2k of changes so it seemed best to just divide it into two parts > (from my approximation there will be 2 more webrevs to finish the umbrella > item JDK-8209547). > > The change is straightforward as before, just a bit repetitive: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210198/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210198 > > I tested this in release mode for the tests that were modified. > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Sep 5 20:00:14 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 5 Sep 2018 13:00:14 -0700 Subject: RFR (S) 8208352: Merge HeapMonitorTest and HeapMonitorGCTest code In-Reply-To: <003536af-7a99-2886-37d8-ae80863b82a7@oracle.com> References: <003536af-7a99-2886-37d8-ae80863b82a7@oracle.com> Message-ID: <2533c0b5-4e40-51cd-a3e6-190ea9ac390c@oracle.com> +1 --alex On 09/05/2018 12:32, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > +1 > > Thanks, > Serguei > > > On 9/5/18 11:59, Chris Plummer wrote: >> Looks good. >> >> Chris >> >> On 9/5/18 11:14 AM, JC Beyler wrote: >>> Hi all, >>> >>> Two of the tests shared code and we could refactor to limit future >>> fixes/changes in both spots. Here is the small webrev that does that: >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8208352/webrev.00/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208352 >>> >>> Thank you for the future reviews, >>> Jc >> >> > From chris.plummer at oracle.com Wed Sep 5 20:04:12 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 13:04:12 -0700 Subject: RFR (M) 8210198: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[A-F] tests In-Reply-To: References: Message-ID: <072683e2-d12a-e8f8-30cf-413fc5c00c54@oracle.com> An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Sep 5 21:32:17 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 5 Sep 2018 14:32:17 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> Message-ID: Hi JC, thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion. I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern. incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html Thanks, -- Igor > On Sep 4, 2018, at 8:01 PM, JC Beyler wrote: > > Hi Igor, > > I reviewed the webrev but I noticed two things: > > - Small nit: > - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html > - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then? > > - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html > - Seems we could refactor a bit this no? > - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized: > > class TaskStream { > private final ByteArrayOutputStream buffer; > private Future task; > > public TaskStream(InputStream stream) { > buffer = new ByteArrayOutputStream(); > task = new StreamPumper(stream, buffer).process(); > } > > public String getBuffer() { > try { > task.get(); > return buffer.toString(); > } catch (InterruptedException e) { > Thread.currentThread().interrupt(); > throw new OutputBufferException(e); > } catch (ExecutionException | CancellationException e) { > throw new OutputBufferException(e); > } > } > } > + class LazyOutputBuffer implements OutputBuffer { > + private final TaskStream stderr; > + private final TaskStream stdout; > + private final Process p; > + > + private LazyOutputBuffer(Process p) { > + this.p = p; > + stderr = new TaskStream(p.getInputStream()); > + stdout = new TaskStream(p.getErrorStream()); > + } > + > + @Override > + public String getStdout() { > + return stdout.getBuffer(); > + } > > + @Override > + public String getStderr() { > + return stderr.getBuffer() > + } > > I think it is more clear, what do you think? > > Apart from those two elements, it looks good to me :), nice refactor! > Jc > > > On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev > wrote: > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > > 2375 lines changed: 322 ins; 1662 del; 391 mod > > Hi all, > > could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process? > > there were a few differences b/w implementations which are addressed by the patch: > - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method > - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family > - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them. > - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest. > > the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible. > > webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html > testing: tier1-tier3 + :jdk_svc > JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 > > Thanks, > -- Igor > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 5 21:59:01 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 5 Sep 2018 14:59:01 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> Message-ID: Hi Igor, I like this much better! A few more comments: - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html ) - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html There is now only a 1-liner for this method and it is called only once, should we inline and remove the method? - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html "There is no lines" -> "There are no lines" - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it Thanks for the incremental webrev, that made looking at the changes so much easier! Jc On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev wrote: > Hi JC, > > thanks for reviewing this! I agree w/ both your comments and have updated > the code very similarly to your suggestion. > > I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method > family is a bit different from other should* (and strange), besides > checking that the lines match the pattern, shouldMatchByLine methods do not > check that it's greater than zero and return number of matched lines > instead. however all users of these methods do check that the return > results is non zero. I have updated these methods to check that there are > lines to match and updated all their users correspondingly. Doing that, I > also made some harmless refactoring, like moving Pattern::compile from > loops, using "\R" as end-of-line pattern. > > incremental webrev: > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html > > Thanks, > -- Igor > > On Sep 4, 2018, at 8:01 PM, JC Beyler wrote: > > Hi Igor, > > I reviewed the webrev but I noticed two things: > > - Small nit: > - In > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html > - I thought we don't have to flush as the stream gets closed and by > closing flushes the stream, isn't that redundant then? > > - > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html > - Seems we could refactor a bit this no? > - If we put the Future and ByteArrayOutputStream in a separate class > (ex TaskStream), then the constructor and the getters could be factorized: > > class TaskStream { > private final ByteArrayOutputStream buffer; > private Future task; > > public TaskStream(InputStream stream) { > buffer = new ByteArrayOutputStream(); > task = new StreamPumper(stream, buffer).process(); > } > > public String getBuffer() { > try { > task.get(); > return buffer.toString(); > } catch (InterruptedException e) { > Thread.currentThread().interrupt(); > throw new OutputBufferException(e); > } catch (ExecutionException | CancellationException e) { > throw new OutputBufferException(e); > } > } > } > > + class LazyOutputBuffer implements OutputBuffer { > > + private final TaskStream stderr; > > + private final TaskStream stdout; > > + private final Process p;++ private LazyOutputBuffer(Process p) {+ this.p = p; > > + stderr = new TaskStream(p.getInputStream()); > > + stdout = new TaskStream(p.getErrorStream());+ }++ @Override+ public String getStdout() { > > + return stdout.getBuffer(); > > + }+ @Override+ public String getStderr() { > > + return stderr.getBuffer()+ } > > > I think it is more clear, what do you think? > > > Apart from those two elements, it looks good to me :), nice refactor! > > Jc > > > > On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev > wrote: > >> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >> > 2375 lines changed: 322 ins; 1662 del; 391 mod >> >> Hi all, >> >> could you please review the patch which removes >> jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages >> w/ corresponding classes from jdk.test.lib.process? >> >> there were a few differences b/w implementations which are addressed by >> the patch: >> - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) >> method >> - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family >> - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any >> purposes, while j.t.OutputBuffer provided lazy access to a process's cout, >> cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface >> w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated >> j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of >> storing them. >> - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but >> j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests >> which really depend on absence of '-cp' and updated them to create >> ProcessBuilder directly, namely JavaClassPathTest and >> AppendToClassPathModuleTest. >> >> the rest of the patch is straightforward change of used classes w/ adding >> @library /test/lib if necessary and removing @library /lib/testlibrary if >> possible. >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >> testing: tier1-tier3 + :jdk_svc >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 >> >> Thanks, >> -- Igor >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Wed Sep 5 22:20:35 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 5 Sep 2018 15:20:35 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> Message-ID: Hi JC, > On Sep 5, 2018, at 2:59 PM, JC Beyler wrote: > > Hi Igor, > > I like this much better! A few more comments: > > - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html > -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html ) just to follow the style used by this tests, e.g. > 54 try { > 55 output.shouldContain(stdout); > 56 output.stdoutShouldContain(stdout); > 57 output.shouldContain(stderr); > 58 output.stderrShouldContain(stderr); > 59 } catch (RuntimeException e) { > 60 throw new Exception("shouldContain() failed", e); > 61 } > 86 try { > 87 output.shouldNotContain(nonExistingString); > 88 output.stdoutShouldNotContain(nonExistingString); > 89 output.stderrShouldNotContain(nonExistingString); > 90 } catch (RuntimeException e) { > 91 throw new Exception("shouldNotContain() failed", e); > 92 } > 93 > - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html > There is now only a 1-liner for this method and it is called only once, should we inline and remove the method? we can, but I ain't sure we should. from my point of view 80 output.shouldHaveExitValue(0); 81 output.shouldContain("sun.tools.jcmd.JCmd"); 82 matchListedProcesses(output); is a bit easier to understand than 80 output.shouldHaveExitValue(0); 81 output.shouldContain("sun.tools.jcmd.JCmd"); 82 output.shouldMatchByLine(JCMD_LIST_REGEX); however, I don't have strong preference here and if serviceability team wants, I can inline matchListedProcesses. > - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html same here > > - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html > "There is no lines" -> "There are no lines" fixed. thanks for spotting. > - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it OutputAnalazyer is supposed to be a fluent interface, and in some cases you might find it used that way, so I'd prefer to have possibility to use these methods in a method chain, as w/ we already have for the the most of other should* method. I've fixed a few more should* methods to return this. > Thanks for the incremental webrev, that made looking at the changes so much easier! here is the next one -- http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html -- Igor > Jc > > On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev > wrote: > Hi JC, > > thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion. > > I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern. > > incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html > > Thanks, > -- Igor > >> On Sep 4, 2018, at 8:01 PM, JC Beyler > wrote: >> >> Hi Igor, >> >> I reviewed the webrev but I noticed two things: >> >> - Small nit: >> - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html >> - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then? >> >> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html >> - Seems we could refactor a bit this no? >> - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized: >> >> class TaskStream { >> private final ByteArrayOutputStream buffer; >> private Future task; >> >> public TaskStream(InputStream stream) { >> buffer = new ByteArrayOutputStream(); >> task = new StreamPumper(stream, buffer).process(); >> } >> >> public String getBuffer() { >> try { >> task.get(); >> return buffer.toString(); >> } catch (InterruptedException e) { >> Thread.currentThread().interrupt(); >> throw new OutputBufferException(e); >> } catch (ExecutionException | CancellationException e) { >> throw new OutputBufferException(e); >> } >> } >> } >> + class LazyOutputBuffer implements OutputBuffer { >> + private final TaskStream stderr; >> + private final TaskStream stdout; >> + private final Process p; >> + >> + private LazyOutputBuffer(Process p) { >> + this.p = p; >> + stderr = new TaskStream(p.getInputStream()); >> + stdout = new TaskStream(p.getErrorStream()); >> + } >> + >> + @Override >> + public String getStdout() { >> + return stdout.getBuffer(); >> + } >> >> + @Override >> + public String getStderr() { >> + return stderr.getBuffer() >> + } >> >> I think it is more clear, what do you think? >> >> Apart from those two elements, it looks good to me :), nice refactor! >> Jc >> >> >> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev > wrote: >> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >> > 2375 lines changed: 322 ins; 1662 del; 391 mod >> >> Hi all, >> >> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process? >> >> there were a few differences b/w implementations which are addressed by the patch: >> - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method >> - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family >> - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them. >> - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest. >> >> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >> testing: tier1-tier3 + :jdk_svc >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 >> >> Thanks, >> -- Igor >> >> >> >> -- >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 6 00:03:29 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 5 Sep 2018 17:03:29 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> Message-ID: Hi Igor, Looks good to me then. I agree most are nits, personal preferences, and just I noticed them as you were cleaning them up! Awesome clean up :-) Jc On Wed, Sep 5, 2018 at 3:20 PM Igor Ignatyev wrote: > Hi JC, > > > On Sep 5, 2018, at 2:59 PM, JC Beyler wrote: > > Hi Igor, > > I like this much better! A few more comments: > > - > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html > -> If the shouldMatch call fails, it throws an exception, why not just > let that fail test, why are you catching and then rethrowing (like you do > for > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html > ) > > just to follow the style used by this tests, e.g. > > 54 try { > 55 output.shouldContain(stdout); > 56 output.stdoutShouldContain(stdout); > 57 output.shouldContain(stderr); > 58 output.stderrShouldContain(stderr); > 59 } catch (RuntimeException e) { > 60 throw new Exception("shouldContain() failed", e); > 61 } > > > 86 try { > 87 output.shouldNotContain(nonExistingString); > 88 output.stdoutShouldNotContain(nonExistingString); > 89 output.stderrShouldNotContain(nonExistingString); > 90 } catch (RuntimeException e) { > 91 throw new Exception("shouldNotContain() failed", e); > 92 } > 93 > > > > - > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html > There is now only a 1-liner for this method and it is called only once, > should we inline and remove the method? > > > we can, but I ain't sure we should. from my point of view > > 80 output.shouldHaveExitValue(0); > 81 output.shouldContain("sun.tools.jcmd.JCmd"); > 82 matchListedProcesses(output); > > is a bit easier to understand than > > 80 output.shouldHaveExitValue(0); > 81 output.shouldContain("sun.tools.jcmd.JCmd"); > 82 output.shouldMatchByLine(JCMD_LIST_REGEX); > > > however, I don't have strong preference here and if serviceability team > wants, I can inline matchListedProcesses. > > - Same for (we could inline): > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html > > same here > > > - > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html > "There is no lines" -> "There are no lines" > > fixed. thanks for spotting. > > - What is the advantage of having the return at all now for the > shouldMatch methods, if it fails it throws, the test fails; otherwise it > doesn't return anything, the test can move on, no? I saw no moment when you > get the return to do something more with it > > OutputAnalazyer is supposed to be a fluent interface, and in some cases > you might find it used that way, so I'd prefer to have possibility to use > these methods in a method chain, as w/ we already have for the the most of > other should* method. I've fixed a few more should* methods to return this. > > > Thanks for the incremental webrev, that made looking at the changes so > much easier! > > > here is the next one -- > http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html > > -- Igor > > Jc > > On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev > wrote: > >> Hi JC, >> >> thanks for reviewing this! I agree w/ both your comments and have updated >> the code very similarly to your suggestion. >> >> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method >> family is a bit different from other should* (and strange), besides >> checking that the lines match the pattern, shouldMatchByLine methods do not >> check that it's greater than zero and return number of matched lines >> instead. however all users of these methods do check that the return >> results is non zero. I have updated these methods to check that there are >> lines to match and updated all their users correspondingly. Doing that, I >> also made some harmless refactoring, like moving Pattern::compile from >> loops, using "\R" as end-of-line pattern. >> >> incremental webrev: >> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html >> >> Thanks, >> -- Igor >> >> On Sep 4, 2018, at 8:01 PM, JC Beyler wrote: >> >> Hi Igor, >> >> I reviewed the webrev but I noticed two things: >> >> - Small nit: >> - In >> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html >> - I thought we don't have to flush as the stream gets closed and by >> closing flushes the stream, isn't that redundant then? >> >> - >> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html >> - Seems we could refactor a bit this no? >> - If we put the Future and ByteArrayOutputStream in a separate class >> (ex TaskStream), then the constructor and the getters could be factorized: >> >> class TaskStream { >> private final ByteArrayOutputStream buffer; >> private Future task; >> >> public TaskStream(InputStream stream) { >> buffer = new ByteArrayOutputStream(); >> task = new StreamPumper(stream, buffer).process(); >> } >> >> public String getBuffer() { >> try { >> task.get(); >> return buffer.toString(); >> } catch (InterruptedException e) { >> Thread.currentThread().interrupt(); >> throw new OutputBufferException(e); >> } catch (ExecutionException | CancellationException e) { >> throw new OutputBufferException(e); >> } >> } >> } >> >> + class LazyOutputBuffer implements OutputBuffer { >> >> + private final TaskStream stderr; >> >> + private final TaskStream stdout; >> >> + private final Process p;++ private LazyOutputBuffer(Process p) {+ this.p = p; >> >> + stderr = new TaskStream(p.getInputStream()); >> >> + stdout = new TaskStream(p.getErrorStream());+ }++ @Override+ public String getStdout() { >> >> + return stdout.getBuffer(); >> >> + }+ @Override+ public String getStderr() { >> >> + return stderr.getBuffer()+ } >> >> >> I think it is more clear, what do you think? >> >> >> Apart from those two elements, it looks good to me :), nice refactor! >> >> Jc >> >> >> >> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev >> wrote: >> >>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >>> > 2375 lines changed: 322 ins; 1662 del; 391 mod >>> >>> Hi all, >>> >>> could you please review the patch which removes >>> jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages >>> w/ corresponding classes from jdk.test.lib.process? >>> >>> there were a few differences b/w implementations which are addressed by >>> the patch: >>> - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) >>> method >>> - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family >>> - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any >>> purposes, while j.t.OutputBuffer provided lazy access to a process's cout, >>> cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface >>> w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated >>> j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of >>> storing them. >>> - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but >>> j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests >>> which really depend on absence of '-cp' and updated them to create >>> ProcessBuilder directly, namely JavaClassPathTest and >>> AppendToClassPathModuleTest. >>> >>> the rest of the patch is straightforward change of used classes w/ >>> adding @library /test/lib if necessary and removing @library >>> /lib/testlibrary if possible. >>> >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >>> testing: tier1-tier3 + :jdk_svc >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 >>> >>> Thanks, >>> -- Igor >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 6 01:39:55 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 5 Sep 2018 18:39:55 -0700 Subject: RFR (L) 8210429: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[G-Z] tests Message-ID: Hi all, Continuing the removal of the JNI_ENV* macros, I have done the other half of the JVMTI Get[G-Z] methods. The final JVMTI test refactoring will come in a final webrev after this one. The change is straightforward as before, just a bit repetitive: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210429/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210429 I tested this in release mode for the tests that were modified. Thanks for your reviews, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 6 03:08:05 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 5 Sep 2018 20:08:05 -0700 Subject: RFR (L) 8210429: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[G-Z] tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Sep 6 16:19:39 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 6 Sep 2018 09:19:39 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> Message-ID: <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com> JC, thanks for your review! Core-libs team, as the majority of changed tests are core-libs tests, I'd really appreciate if someone from core-libs (preferably a Reviewer) could review the patch. for the record, [1] is the latest version of webrev. [1] http://cr.openjdk.java.net/~iignatyev//8210112/webrev.02/index.html > 2433 lines changed: 334 ins; 1677 del; 422 mod; Cheers, -- Igor > On Sep 5, 2018, at 5:03 PM, JC Beyler wrote: > > Hi Igor, > > Looks good to me then. I agree most are nits, personal preferences, and just I noticed them as you were cleaning them up! > > Awesome clean up :-) > Jc > > On Wed, Sep 5, 2018 at 3:20 PM Igor Ignatyev > wrote: > Hi JC, > > >> On Sep 5, 2018, at 2:59 PM, JC Beyler > wrote: >> >> Hi Igor, >> >> I like this much better! A few more comments: >> >> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html >> -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html ) > just to follow the style used by this tests, e.g. > >> 54 try { >> 55 output.shouldContain(stdout); >> 56 output.stdoutShouldContain(stdout); >> 57 output.shouldContain(stderr); >> 58 output.stderrShouldContain(stderr); >> 59 } catch (RuntimeException e) { >> 60 throw new Exception("shouldContain() failed", e); >> 61 } > >> 86 try { >> 87 output.shouldNotContain(nonExistingString); >> 88 output.stdoutShouldNotContain(nonExistingString); >> 89 output.stderrShouldNotContain(nonExistingString); >> 90 } catch (RuntimeException e) { >> 91 throw new Exception("shouldNotContain() failed", e); >> 92 } >> 93 > > >> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html >> There is now only a 1-liner for this method and it is called only once, should we inline and remove the method? > > we can, but I ain't sure we should. from my point of view > > 80 output.shouldHaveExitValue(0); > 81 output.shouldContain("sun.tools.jcmd.JCmd"); > 82 matchListedProcesses(output); > is a bit easier to understand than > 80 output.shouldHaveExitValue(0); > 81 output.shouldContain("sun.tools.jcmd.JCmd"); > 82 output.shouldMatchByLine(JCMD_LIST_REGEX); > > however, I don't have strong preference here and if serviceability team wants, I can inline matchListedProcesses. > >> - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html same here > >> >> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html >> "There is no lines" -> "There are no lines" > fixed. thanks for spotting. > >> - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it > OutputAnalazyer is supposed to be a fluent interface, and in some cases you might find it used that way, so I'd prefer to have possibility to use these methods in a method chain, as w/ we already have for the the most of other should* method. I've fixed a few more should* methods to return this. > > >> Thanks for the incremental webrev, that made looking at the changes so much easier! > > here is the next one -- http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html > > -- Igor >> Jc >> >> On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev > wrote: >> Hi JC, >> >> thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion. >> >> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern. >> >> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html >> >> Thanks, >> -- Igor >> >>> On Sep 4, 2018, at 8:01 PM, JC Beyler > wrote: >>> >>> Hi Igor, >>> >>> I reviewed the webrev but I noticed two things: >>> >>> - Small nit: >>> - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html >>> - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then? >>> >>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html >>> - Seems we could refactor a bit this no? >>> - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized: >>> >>> class TaskStream { >>> private final ByteArrayOutputStream buffer; >>> private Future task; >>> >>> public TaskStream(InputStream stream) { >>> buffer = new ByteArrayOutputStream(); >>> task = new StreamPumper(stream, buffer).process(); >>> } >>> >>> public String getBuffer() { >>> try { >>> task.get(); >>> return buffer.toString(); >>> } catch (InterruptedException e) { >>> Thread.currentThread().interrupt(); >>> throw new OutputBufferException(e); >>> } catch (ExecutionException | CancellationException e) { >>> throw new OutputBufferException(e); >>> } >>> } >>> } >>> + class LazyOutputBuffer implements OutputBuffer { >>> + private final TaskStream stderr; >>> + private final TaskStream stdout; >>> + private final Process p; >>> + >>> + private LazyOutputBuffer(Process p) { >>> + this.p = p; >>> + stderr = new TaskStream(p.getInputStream()); >>> + stdout = new TaskStream(p.getErrorStream()); >>> + } >>> + >>> + @Override >>> + public String getStdout() { >>> + return stdout.getBuffer(); >>> + } >>> >>> + @Override >>> + public String getStderr() { >>> + return stderr.getBuffer() >>> + } >>> >>> I think it is more clear, what do you think? >>> >>> Apart from those two elements, it looks good to me :), nice refactor! >>> Jc >>> >>> >>> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev > wrote: >>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >>> > 2375 lines changed: 322 ins; 1662 del; 391 mod >>> >>> Hi all, >>> >>> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process? >>> >>> there were a few differences b/w implementations which are addressed by the patch: >>> - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method >>> - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family >>> - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them. >>> - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest. >>> >>> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >>> testing: tier1-tier3 + :jdk_svc >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 >>> >>> Thanks, >>> -- Igor >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> >> >> -- >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 7 05:32:32 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 6 Sep 2018 22:32:32 -0700 Subject: RFR (L) 8210429: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[G-Z] tests In-Reply-To: References: Message-ID: Thanks Chris, anybody else motivated to review this? Thanks in advance! Jc On Wed, Sep 5, 2018 at 8:08 PM Chris Plummer wrote: > Hi JC, > > In getstacktr008.cpp, this should be one line: > > 240 classDef.class_byte_count = > 241 env->GetArrayLength(classBytes); > > Otherwise looks great! > > Chris > > On 9/5/18 6:39 PM, JC Beyler wrote: > > Hi all, > > Continuing the removal of the JNI_ENV* macros, I have done the other half > of the JVMTI Get[G-Z] methods. The final JVMTI test refactoring will come > in a final webrev after this one. > > The change is straightforward as before, just a bit repetitive: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210429/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210429 > > I tested this in release mode for the tests that were modified. > > Thanks for your reviews, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Sep 7 05:57:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Sep 2018 15:57:25 +1000 Subject: RFR (L) 8210429: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[G-Z] tests In-Reply-To: References: Message-ID: <5a09bd41-1d8a-6ab0-477d-c7a6d147aaec@oracle.com> Hi Jc, On 7/09/2018 3:32 PM, JC Beyler wrote: > Thanks Chris, anybody else motivated to review this? I skimmed through it and it all seemed okay. Thanks, David > Thanks in advance! > Jc > > On Wed, Sep 5, 2018 at 8:08 PM Chris Plummer > wrote: > > Hi JC, > > In getstacktr008.cpp, this should be one line: > > ?240???????? classDef.class_byte_count = > ?241???????????? env->GetArrayLength(classBytes); > > Otherwise looks great! > > Chris > > On 9/5/18 6:39 PM, JC Beyler wrote: >> Hi all, >> >> Continuing the removal of the JNI_ENV* macros, I have done the >> other half of the JVMTI Get[G-Z] methods. The final JVMTI test >> refactoring will come in a final webrev after this one. >> >> The change is straightforward as before, just a bit repetitive: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210429/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210429 >> >> I tested this in release mode for the tests that were modified. >> >> Thanks for your reviews, >> Jc > > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Fri Sep 7 06:29:56 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 6 Sep 2018 23:29:56 -0700 Subject: RFR (L) 8210429: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[G-Z] tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Sep 7 08:05:12 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Sep 2018 01:05:12 -0700 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com> References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com> Message-ID: Hi Igor, I do not see any issues with this refactoring. Thanks, Serguei On 9/6/18 09:19, Igor Ignatyev wrote: > JC, > thanks for your review! > > Core-libs team, > as the majority of changed tests are core-libs tests, I'd really appreciate if someone from core-libs (preferably a Reviewer) could review the patch. > > for the record, [1] is the latest version of webrev. > > [1] http://cr.openjdk.java.net/~iignatyev//8210112/webrev.02/index.html >> 2433 lines changed: 334 ins; 1677 del; 422 mod; > Cheers, > -- Igor > > >> On Sep 5, 2018, at 5:03 PM, JC Beyler wrote: >> >> Hi Igor, >> >> Looks good to me then. I agree most are nits, personal preferences, and just I noticed them as you were cleaning them up! >> >> Awesome clean up :-) >> Jc >> >> On Wed, Sep 5, 2018 at 3:20 PM Igor Ignatyev > wrote: >> Hi JC, >> >> >>> On Sep 5, 2018, at 2:59 PM, JC Beyler > wrote: >>> >>> Hi Igor, >>> >>> I like this much better! A few more comments: >>> >>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/lib/testlibrary/OutputAnalyzerTest.java.udiff.html >>> -> If the shouldMatch call fails, it throws an exception, why not just let that fail test, why are you catching and then rethrowing (like you do for http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html ) >> just to follow the style used by this tests, e.g. >> >>> 54 try { >>> 55 output.shouldContain(stdout); >>> 56 output.stdoutShouldContain(stdout); >>> 57 output.shouldContain(stderr); >>> 58 output.stderrShouldContain(stderr); >>> 59 } catch (RuntimeException e) { >>> 60 throw new Exception("shouldContain() failed", e); >>> 61 } >>> 86 try { >>> 87 output.shouldNotContain(nonExistingString); >>> 88 output.stdoutShouldNotContain(nonExistingString); >>> 89 output.stderrShouldNotContain(nonExistingString); >>> 90 } catch (RuntimeException e) { >>> 91 throw new Exception("shouldNotContain() failed", e); >>> 92 } >>> 93 >> >>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdDefaults.java.udiff.html >>> There is now only a 1-liner for this method and it is called only once, should we inline and remove the method? >> we can, but I ain't sure we should. from my point of view >> >> 80 output.shouldHaveExitValue(0); >> 81 output.shouldContain("sun.tools.jcmd.JCmd"); >> 82 matchListedProcesses(output); >> is a bit easier to understand than >> 80 output.shouldHaveExitValue(0); >> 81 output.shouldContain("sun.tools.jcmd.JCmd"); >> 82 output.shouldMatchByLine(JCMD_LIST_REGEX); >> >> however, I don't have strong preference here and if serviceability team wants, I can inline matchListedProcesses. >> >>> - Same for (we could inline): http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/jdk/sun/tools/jcmd/TestJcmdSanity.java.udiff.html same here >>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/test/lib/jdk/test/lib/process/OutputAnalyzer.java.udiff.html >>> "There is no lines" -> "There are no lines" >> fixed. thanks for spotting. >> >>> - What is the advantage of having the return at all now for the shouldMatch methods, if it fails it throws, the test fails; otherwise it doesn't return anything, the test can move on, no? I saw no moment when you get the return to do something more with it >> OutputAnalazyer is supposed to be a fluent interface, and in some cases you might find it used that way, so I'd prefer to have possibility to use these methods in a method chain, as w/ we already have for the the most of other should* method. I've fixed a few more should* methods to return this. >> >> >>> Thanks for the incremental webrev, that made looking at the changes so much easier! >> here is the next one -- http://cr.openjdk.java.net/~iignatyev//8210112/webrev.1-2/index.html >> >> -- Igor >>> Jc >>> >>> On Wed, Sep 5, 2018 at 2:32 PM Igor Ignatyev > wrote: >>> Hi JC, >>> >>> thanks for reviewing this! I agree w/ both your comments and have updated the code very similarly to your suggestion. >>> >>> I've also noticed that j.t.l.p.OutputAnalyzer::shouldMatchByLine method family is a bit different from other should* (and strange), besides checking that the lines match the pattern, shouldMatchByLine methods do not check that it's greater than zero and return number of matched lines instead. however all users of these methods do check that the return results is non zero. I have updated these methods to check that there are lines to match and updated all their users correspondingly. Doing that, I also made some harmless refactoring, like moving Pattern::compile from loops, using "\R" as end-of-line pattern. >>> >>> incremental webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.0-1/index.html >>> >>> Thanks, >>> -- Igor >>> >>>> On Sep 4, 2018, at 8:01 PM, JC Beyler > wrote: >>>> >>>> Hi Igor, >>>> >>>> I reviewed the webrev but I noticed two things: >>>> >>>> - Small nit: >>>> - In http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/ProcessTools.java.udiff.html >>>> - I thought we don't have to flush as the stream gets closed and by closing flushes the stream, isn't that redundant then? >>>> >>>> - http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/test/lib/jdk/test/lib/process/OutputBuffer.java.udiff.html >>>> - Seems we could refactor a bit this no? >>>> - If we put the Future and ByteArrayOutputStream in a separate class (ex TaskStream), then the constructor and the getters could be factorized: >>>> >>>> class TaskStream { >>>> private final ByteArrayOutputStream buffer; >>>> private Future task; >>>> >>>> public TaskStream(InputStream stream) { >>>> buffer = new ByteArrayOutputStream(); >>>> task = new StreamPumper(stream, buffer).process(); >>>> } >>>> >>>> public String getBuffer() { >>>> try { >>>> task.get(); >>>> return buffer.toString(); >>>> } catch (InterruptedException e) { >>>> Thread.currentThread().interrupt(); >>>> throw new OutputBufferException(e); >>>> } catch (ExecutionException | CancellationException e) { >>>> throw new OutputBufferException(e); >>>> } >>>> } >>>> } >>>> + class LazyOutputBuffer implements OutputBuffer { >>>> + private final TaskStream stderr; >>>> + private final TaskStream stdout; >>>> + private final Process p; >>>> + >>>> + private LazyOutputBuffer(Process p) { >>>> + this.p = p; >>>> + stderr = new TaskStream(p.getInputStream()); >>>> + stdout = new TaskStream(p.getErrorStream()); >>>> + } >>>> + >>>> + @Override >>>> + public String getStdout() { >>>> + return stdout.getBuffer(); >>>> + } >>>> >>>> + @Override >>>> + public String getStderr() { >>>> + return stderr.getBuffer() >>>> + } >>>> >>>> I think it is more clear, what do you think? >>>> >>>> Apart from those two elements, it looks good to me :), nice refactor! >>>> Jc >>>> >>>> >>>> On Tue, Sep 4, 2018 at 6:33 PM Igor Ignatyev > wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >>>>> 2375 lines changed: 322 ins; 1662 del; 391 mod >>>> Hi all, >>>> >>>> could you please review the patch which removes jdk.testlibrary.ProcessTools and its friends and replaces all theirs usages w/ corresponding classes from jdk.test.lib.process? >>>> >>>> there were a few differences b/w implementations which are addressed by the patch: >>>> - j.t.l.p.ProcessTools missed executeProcess(ProcessBuilder, String) method >>>> - j.t.l.p.OutputAnalyzer didn't have shouldMatchByLine methods family >>>> - j.t.l.p.OutputBuffer was a very rudimentary and didn't serve any purposes, while j.t.OutputBuffer provided lazy access to a process's cout, cerr and exitcode. I have changed j.t.l.p.OutputBuffer to be an interface w/ two implementations LazyOutputBuffer and EagerOutputBuffer, and updated j.t.l.p.OutputAnalyzer to get values from an OutputBuffer instead of storing them. >>>> - j.t.l.p.ProcessTools::createJavaProcessBuilder always adds '-cp', but j.t.ProcessTools::createJavaProcessBuilder did not. I have identified tests which really depend on absence of '-cp' and updated them to create ProcessBuilder directly, namely JavaClassPathTest and AppendToClassPathModuleTest. >>>> >>>> the rest of the patch is straightforward change of used classes w/ adding @library /test/lib if necessary and removing @library /lib/testlibrary if possible. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8210112/webrev.00/index.html >>>> testing: tier1-tier3 + :jdk_svc >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210112 >>>> >>>> Thanks, >>>> -- Igor >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> >> -- >> >> Thanks, >> Jc From david.holmes at oracle.com Fri Sep 7 08:51:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Sep 2018 18:51:54 +1000 Subject: RFR: (trivial) 8210486: Unused code in check_nest_attributes function Message-ID: <11b438b1-821e-71bd-bad4-b0a35a2844aa@oracle.com> Thanks to Mikael V. for finding this. :) Bug: https://bugs.openjdk.java.net/browse/JDK-8210486 Webrev: http://cr.openjdk.java.net/~dholmes/8210486/webrev/ Trivial code cleanup of unused variable: --- old/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:40.369608675 -0400 +++ new/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:38.797517530 -0400 @@ -699,7 +699,6 @@ // Check whether the class NestHost attribute has been changed. Thread* thread = Thread::current(); ResourceMark rm(thread); - JvmtiThreadState *state = JvmtiThreadState::state_for((JavaThread*)thread); u2 the_nest_host_idx = the_class->nest_host_index(); u2 scr_nest_host_idx = scratch_class->nest_host_index(); Testing: - jdk/com/sun/jdi - jdk/java/lang/instrument - hotspot/runtime/Redefine* - hotspot/runtime/appcds/redefineClass - tiers 1-3 (mach5) Thanks, David From mikael.vidstedt at oracle.com Fri Sep 7 08:55:08 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 7 Sep 2018 01:55:08 -0700 Subject: RFR: (trivial) 8210486: Unused code in check_nest_attributes function In-Reply-To: <11b438b1-821e-71bd-bad4-b0a35a2844aa@oracle.com> References: <11b438b1-821e-71bd-bad4-b0a35a2844aa@oracle.com> Message-ID: <0F22069A-6BBE-4EA1-B1E9-0CAC05445928@oracle.com> Looks good. Thanks for fixing! Cheers, Mikael > On Sep 7, 2018, at 1:51 AM, David Holmes wrote: > > Thanks to Mikael V. for finding this. :) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210486 > Webrev: http://cr.openjdk.java.net/~dholmes/8210486/webrev/ > > Trivial code cleanup of unused variable: > > --- old/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:40.369608675 -0400 > +++ new/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:38.797517530 -0400 > @@ -699,7 +699,6 @@ > // Check whether the class NestHost attribute has been changed. > Thread* thread = Thread::current(); > ResourceMark rm(thread); > - JvmtiThreadState *state = JvmtiThreadState::state_for((JavaThread*)thread); > u2 the_nest_host_idx = the_class->nest_host_index(); > u2 scr_nest_host_idx = scratch_class->nest_host_index(); > > Testing: > - jdk/com/sun/jdi > - jdk/java/lang/instrument > - hotspot/runtime/Redefine* > - hotspot/runtime/appcds/redefineClass > - tiers 1-3 (mach5) > > Thanks, > David > > From david.holmes at oracle.com Fri Sep 7 08:57:37 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Sep 2018 18:57:37 +1000 Subject: RFR: (trivial) 8210486: Unused code in check_nest_attributes function In-Reply-To: <0F22069A-6BBE-4EA1-B1E9-0CAC05445928@oracle.com> References: <11b438b1-821e-71bd-bad4-b0a35a2844aa@oracle.com> <0F22069A-6BBE-4EA1-B1E9-0CAC05445928@oracle.com> Message-ID: Thanks Mikael! David On 7/09/2018 6:55 PM, Mikael Vidstedt wrote: > > Looks good. Thanks for fixing! > > Cheers, > Mikael > > >> On Sep 7, 2018, at 1:51 AM, David Holmes wrote: >> >> Thanks to Mikael V. for finding this. :) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210486 >> Webrev: http://cr.openjdk.java.net/~dholmes/8210486/webrev/ >> >> Trivial code cleanup of unused variable: >> >> --- old/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:40.369608675 -0400 >> +++ new/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:38.797517530 -0400 >> @@ -699,7 +699,6 @@ >> // Check whether the class NestHost attribute has been changed. >> Thread* thread = Thread::current(); >> ResourceMark rm(thread); >> - JvmtiThreadState *state = JvmtiThreadState::state_for((JavaThread*)thread); >> u2 the_nest_host_idx = the_class->nest_host_index(); >> u2 scr_nest_host_idx = scratch_class->nest_host_index(); >> >> Testing: >> - jdk/com/sun/jdi >> - jdk/java/lang/instrument >> - hotspot/runtime/Redefine* >> - hotspot/runtime/appcds/redefineClass >> - tiers 1-3 (mach5) >> >> Thanks, >> David >> >> > From serguei.spitsyn at oracle.com Fri Sep 7 09:17:05 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 7 Sep 2018 02:17:05 -0700 Subject: RFR: (trivial) 8210486: Unused code in check_nest_attributes function In-Reply-To: <0F22069A-6BBE-4EA1-B1E9-0CAC05445928@oracle.com> References: <11b438b1-821e-71bd-bad4-b0a35a2844aa@oracle.com> <0F22069A-6BBE-4EA1-B1E9-0CAC05445928@oracle.com> Message-ID: <56147124-6f87-81ef-6459-de1121f7fd15@oracle.com> +1 Thanks, Serguei On 9/7/18 01:55, Mikael Vidstedt wrote: > Looks good. Thanks for fixing! > > Cheers, > Mikael > > >> On Sep 7, 2018, at 1:51 AM, David Holmes wrote: >> >> Thanks to Mikael V. for finding this. :) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210486 >> Webrev: http://cr.openjdk.java.net/~dholmes/8210486/webrev/ >> >> Trivial code cleanup of unused variable: >> >> --- old/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:40.369608675 -0400 >> +++ new/src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2018-09-07 04:39:38.797517530 -0400 >> @@ -699,7 +699,6 @@ >> // Check whether the class NestHost attribute has been changed. >> Thread* thread = Thread::current(); >> ResourceMark rm(thread); >> - JvmtiThreadState *state = JvmtiThreadState::state_for((JavaThread*)thread); >> u2 the_nest_host_idx = the_class->nest_host_index(); >> u2 scr_nest_host_idx = scratch_class->nest_host_index(); >> >> Testing: >> - jdk/com/sun/jdi >> - jdk/java/lang/instrument >> - hotspot/runtime/Redefine* >> - hotspot/runtime/appcds/redefineClass >> - tiers 1-3 (mach5) >> >> Thanks, >> David >> >> From david.holmes at oracle.com Fri Sep 7 10:23:37 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Sep 2018 20:23:37 +1000 Subject: RFR: (trivial) 8210486: Unused code in check_nest_attributes function In-Reply-To: <56147124-6f87-81ef-6459-de1121f7fd15@oracle.com> References: <11b438b1-821e-71bd-bad4-b0a35a2844aa@oracle.com> <0F22069A-6BBE-4EA1-B1E9-0CAC05445928@oracle.com> <56147124-6f87-81ef-6459-de1121f7fd15@oracle.com> Message-ID: Thanks Serguei! David On 7/09/2018 7:17 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Thanks, > Serguei > > On 9/7/18 01:55, Mikael Vidstedt wrote: >> Looks good. Thanks for fixing! >> >> Cheers, >> Mikael >> >> >>> On Sep 7, 2018, at 1:51 AM, David Holmes >>> wrote: >>> >>> Thanks to Mikael V. for finding this. :) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210486 >>> Webrev: http://cr.openjdk.java.net/~dholmes/8210486/webrev/ >>> >>> Trivial code cleanup of unused variable: >>> >>> --- old/src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>> 2018-09-07 04:39:40.369608675 -0400 >>> +++ new/src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>> 2018-09-07 04:39:38.797517530 -0400 >>> @@ -699,7 +699,6 @@ >>> ?? // Check whether the class NestHost attribute has been changed. >>> ?? Thread* thread = Thread::current(); >>> ?? ResourceMark rm(thread); >>> -? JvmtiThreadState *state = >>> JvmtiThreadState::state_for((JavaThread*)thread); >>> ?? u2 the_nest_host_idx = the_class->nest_host_index(); >>> ?? u2 scr_nest_host_idx = scratch_class->nest_host_index(); >>> >>> Testing: >>> ? - jdk/com/sun/jdi >>> ? - jdk/java/lang/instrument >>> ? - hotspot/runtime/Redefine* >>> ? - hotspot/runtime/appcds/redefineClass >>> ? - tiers 1-3 (mach5) >>> >>> Thanks, >>> David >>> >>> > From Alan.Bateman at oracle.com Fri Sep 7 13:05:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Sep 2018 14:05:57 +0100 Subject: RFR(L/M) : 8210112 : remove jdk.testlibrary.ProcessTools In-Reply-To: <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com> References: <4B505579-23D5-4058-B087-B7CFDED8A66A@oracle.com> <01D7CD16-A1B8-4EC5-9B5C-9F61BD984789@oracle.com> Message-ID: On 06/09/2018 17:19, Igor Ignatyev wrote: > JC, > thanks for your review! > > Core-libs team, > as the majority of changed tests are core-libs tests, I'd really appreciate if someone from core-libs (preferably a Reviewer) could review the patch. > > I skimmed through a sample of the test changes and was pleased to see that it's just the test tags that have changed. Also pleased to see that the shouldXXX methods now consistently return the OutputAnalyzer (this seems to be one area where the version in testlibrary was different). I don't have time to do a detail review of the updated ProcessTools/OutputAnalyzer but I think you have enough reviewers already. -Alan From jcbeyler at google.com Fri Sep 7 16:41:48 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 7 Sep 2018 09:41:48 -0700 Subject: RFR (L) 8210429: Clean up JNI_ENV_ARG for vmTestbase/jvmti/Get[G-Z] tests In-Reply-To: References: Message-ID: Thanks David and Serguei, @Serguei: I now added a double check for any change I make to ensure that I put them on the same line when the line is small (btw, you indeed found the only case where I missed it) Have a great weekend, Jc On Thu, Sep 6, 2018 at 11:30 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > It looks to me. > One minor comment. > > > http://cr.openjdk.java.net/%7Ejcbeyler/8210429/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetMethodDeclaringClass/declcls001/declcls001.cpp.udiff.html > > - mid = JNI_ENV_PTR(env)->GetStaticMethodID(JNI_ENV_ARG(env, cl),+ mid = env->GetStaticMethodID(cl, > name, sig); > > I'd suggest to replace to place the call to just one line. > > > No need for another webrev if you fix it. > > Thanks, > Serguei > > > On 9/5/18 18:39, JC Beyler wrote: > > Hi all, > > Continuing the removal of the JNI_ENV* macros, I have done the other half > of the JVMTI Get[G-Z] methods. The final JVMTI test refactoring will come > in a final webrev after this one. > > The change is straightforward as before, just a bit repetitive: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210429/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210429 > > I tested this in release mode for the tests that were modified. > > Thanks for your reviews, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 7 17:53:59 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 7 Sep 2018 10:53:59 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests Message-ID: Hi all, I'm taking the risk to perhaps do something too huge but as it is the same as the previous ones (and the last one!): It's 4k of changes, for that I apologize. I can divide it up in 2/3 parts again if you want or we can just do it in one go since now some reviewers know what to expect. There still is a bit of refactoring to the vmTestbase but this will in essence finish: - Removing the JNI_ENV* and JVMTI_ENV* macros for the vmTestbase Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 Thanks for your reviews and let me know if you would prefer me to cut it up like I did the Get[A-F] & Get[G-Z] ones, Jc Ps: for the curious, then we can start cleaning up the native code a bit more sanely (example: JDK-8191519) and there will be one more webrev removing #ifdef cplusplus lingering in the vmTestbase (JDK-8210481). -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 7 18:34:28 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 7 Sep 2018 11:34:28 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: Message-ID: Hi Jc, I'd prefer to see the fix splitted to smaller parts. The changes are quite simple, but it's just too many files, so it's impossible (at least for me) to review them accurately. --alex On 09/07/2018 10:53, JC Beyler wrote: > Hi all, > > I'm taking the risk to perhaps do something too huge but as it is the > same as the previous ones (and the last one!): > > It's 4k of changes, for that I apologize. I can divide it up in 2/3 > parts again if you want or we can just do it in one go since now some > reviewers know what to expect. There still is a bit of refactoring to > the vmTestbase but this will in essence finish: > ? - Removing the JNI_ENV* and JVMTI_ENV* macros for the vmTestbase > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > Thanks for your reviews and let me know if you would prefer me to cut it > up like I did the Get[A-F] & Get[G-Z] ones, > Jc > > Ps: for the curious, then we can start cleaning up the native code a bit > more sanely (example: JDK-8191519) and there will be one more webrev > removing #ifdef cplusplus lingering in the vmTestbase (JDK-8210481). > From jcbeyler at google.com Fri Sep 7 18:37:42 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 7 Sep 2018 11:37:42 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: Message-ID: Sounds good to me, would you prefer it in 4 webrevs of 1k changes? Or 2 webrevs of 2k changes? I can do either easily, so just let me know; your job as the reviewer is harder for these :) Jc On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov wrote: > Hi Jc, > > I'd prefer to see the fix splitted to smaller parts. > The changes are quite simple, but it's just too many files, so it's > impossible (at least for me) to review them accurately. > > --alex > > On 09/07/2018 10:53, JC Beyler wrote: > > Hi all, > > > > I'm taking the risk to perhaps do something too huge but as it is the > > same as the previous ones (and the last one!): > > > > It's 4k of changes, for that I apologize. I can divide it up in 2/3 > > parts again if you want or we can just do it in one go since now some > > reviewers know what to expect. There still is a bit of refactoring to > > the vmTestbase but this will in essence finish: > > - Removing the JNI_ENV* and JVMTI_ENV* macros for the vmTestbase > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > Thanks for your reviews and let me know if you would prefer me to cut it > > up like I did the Get[A-F] & Get[G-Z] ones, > > Jc > > > > Ps: for the curious, then we can start cleaning up the native code a bit > > more sanely (example: JDK-8191519) and there will be one more webrev > > removing #ifdef cplusplus lingering in the vmTestbase (JDK-8210481). > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 7 18:51:01 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 7 Sep 2018 11:51:01 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: Message-ID: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> I think ~40-50 files per fix is my maximum :) --alex On 09/07/2018 11:37, JC Beyler wrote: > Sounds good to me, would you prefer it in 4 webrevs of 1k changes? Or 2 > webrevs of 2k changes? > > I can do either easily, so just let me know; your job as the reviewer is > harder for these :) > Jc > > On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov > wrote: > > Hi Jc, > > I'd prefer to see the fix splitted to smaller parts. > The changes are quite simple, but it's just too many files, so it's > impossible (at least for me) to review them accurately. > > --alex > > On 09/07/2018 10:53, JC Beyler wrote: > > Hi all, > > > > I'm taking the risk to perhaps do something too huge but as it is > the > > same as the previous ones (and the last one!): > > > > It's 4k of changes, for that I apologize. I can divide it up in 2/3 > > parts again if you want or we can just do it in one go since now > some > > reviewers know what to expect. There still is a bit of > refactoring to > > the vmTestbase but this will in essence finish: > >? ? - Removing the JNI_ENV* and JVMTI_ENV* macros for the vmTestbase > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > Thanks for your reviews and let me know if you would prefer me to > cut it > > up like I did the Get[A-F] & Get[G-Z] ones, > > Jc > > > > Ps: for the curious, then we can start cleaning up the native > code a bit > > more sanely (example: JDK-8191519) and there will be one more webrev > > removing #ifdef cplusplus lingering in the vmTestbase (JDK-8210481). > > > > > > -- > > Thanks, > Jc From jcbeyler at google.com Fri Sep 7 19:22:16 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 7 Sep 2018 12:22:16 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> References: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> Message-ID: Hi Alex, Sounds good to me, I'll aim between 40~50 files then :) Here is the jvmti/A-N* remaining refactoring of the JNI_ENV* / JVMTI_ENV* macros: I have updated the bug to reflect this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 Thanks again! Jc On Fri, Sep 7, 2018 at 11:51 AM Alex Menkov wrote: > I think ~40-50 files per fix is my maximum :) > > --alex > > On 09/07/2018 11:37, JC Beyler wrote: > > Sounds good to me, would you prefer it in 4 webrevs of 1k changes? Or 2 > > webrevs of 2k changes? > > > > I can do either easily, so just let me know; your job as the reviewer is > > harder for these :) > > Jc > > > > On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov > > wrote: > > > > Hi Jc, > > > > I'd prefer to see the fix splitted to smaller parts. > > The changes are quite simple, but it's just too many files, so it's > > impossible (at least for me) to review them accurately. > > > > --alex > > > > On 09/07/2018 10:53, JC Beyler wrote: > > > Hi all, > > > > > > I'm taking the risk to perhaps do something too huge but as it is > > the > > > same as the previous ones (and the last one!): > > > > > > It's 4k of changes, for that I apologize. I can divide it up in > 2/3 > > > parts again if you want or we can just do it in one go since now > > some > > > reviewers know what to expect. There still is a bit of > > refactoring to > > > the vmTestbase but this will in essence finish: > > > - Removing the JNI_ENV* and JVMTI_ENV* macros for the > vmTestbase > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > > > Thanks for your reviews and let me know if you would prefer me to > > cut it > > > up like I did the Get[A-F] & Get[G-Z] ones, > > > Jc > > > > > > Ps: for the curious, then we can start cleaning up the native > > code a bit > > > more sanely (example: JDK-8191519) and there will be one more > webrev > > > removing #ifdef cplusplus lingering in the vmTestbase > (JDK-8210481). > > > > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 7 21:07:11 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 7 Sep 2018 14:07:11 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> Message-ID: Hi Jc, The fix looks good. The only note: test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.cpp contains double jvmti initialization: - res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), - JVMTI_VERSION_1_1); + res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); if (res != JNI_OK || jvmti == NULL) { printf("Wrong result of a valid call to GetEnv!\n"); return JNI_ERR; } - res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), - JVMTI_VERSION_1_1); + res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); if (res != JNI_OK || jvmti == NULL) { printf("Wrong result of a valid call to GetEnv!\n"); return JNI_ERR; } Could you please remove one of them. --alex On 09/07/2018 12:22, JC Beyler wrote: > Hi Alex, > > Sounds good to me, I'll aim between 40~50 files then :) > > Here is the jvmti/A-N* remaining refactoring of the JNI_ENV* / > JVMTI_ENV* macros: > > I have updated the bug to reflect this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > Thanks again! > Jc > > > On Fri, Sep 7, 2018 at 11:51 AM Alex Menkov > wrote: > > I think ~40-50 files per fix is my maximum :) > > --alex > > On 09/07/2018 11:37, JC Beyler wrote: > > Sounds good to me, would you prefer it in 4 webrevs of 1k > changes? Or 2 > > webrevs of 2k changes? > > > > I can do either easily, so just let me know; your job as the > reviewer is > > harder for these :) > > Jc > > > > On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?I'd prefer to see the fix splitted to smaller parts. > >? ? ?The changes are quite simple, but it's just too many files, > so it's > >? ? ?impossible (at least for me) to review them accurately. > > > >? ? ?--alex > > > >? ? ?On 09/07/2018 10:53, JC Beyler wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > I'm taking the risk to perhaps do something too huge but > as it is > >? ? ?the > >? ? ? > same as the previous ones (and the last one!): > >? ? ? > > >? ? ? > It's 4k of changes, for that I apologize. I can divide it > up in 2/3 > >? ? ? > parts again if you want or we can just do it in one go > since now > >? ? ?some > >? ? ? > reviewers know what to expect. There still is a bit of > >? ? ?refactoring to > >? ? ? > the vmTestbase but this will in essence finish: > >? ? ? >? ? - Removing the JNI_ENV* and JVMTI_ENV* macros for the > vmTestbase > >? ? ? > > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > >? ? ? > >? ? ? > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > >? ? ? > > >? ? ? > Thanks for your reviews and let me know if you would > prefer me to > >? ? ?cut it > >? ? ? > up like I did the Get[A-F] & Get[G-Z] ones, > >? ? ? > Jc > >? ? ? > > >? ? ? > Ps: for the curious, then we can start cleaning up the native > >? ? ?code a bit > >? ? ? > more sanely (example: JDK-8191519) and there will be one > more webrev > >? ? ? > removing #ifdef cplusplus lingering in the vmTestbase > (JDK-8210481). > >? ? ? > > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From igor.ignatyev at oracle.com Fri Sep 7 22:11:33 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 7 Sep 2018 15:11:33 -0700 Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and JDKToolLauncher Message-ID: http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html > 327 lines changed: 13 ins; 270 del; 44 mod; Hi all, could you please review the patch which removes jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively? JBS: https://bugs.openjdk.java.net/browse/JDK-8182404 webrev: http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html testing: tier1-3 + :jdk_svc Thanks, -- Igor From alexey.menkov at oracle.com Sat Sep 8 00:45:30 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 7 Sep 2018 17:45:30 -0700 Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and JDKToolLauncher In-Reply-To: References: Message-ID: Hi Igor, Looks good. --alex On 09/07/2018 15:11, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html >> 327 lines changed: 13 ins; 270 del; 44 mod; > > Hi all, > > could you please review the patch which removes jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8182404 > webrev: http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html > testing: tier1-3 + :jdk_svc > > Thanks, > -- Igor > From jcbeyler at google.com Sat Sep 8 01:03:06 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 7 Sep 2018 18:03:06 -0700 Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and JDKToolLauncher In-Reply-To: References: Message-ID: Hi Igor, Looks good to me as well, nice job :-) Jc On Fri, Sep 7, 2018 at 5:46 PM Alex Menkov wrote: > Hi Igor, > > Looks good. > > --alex > > On 09/07/2018 15:11, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html > >> 327 lines changed: 13 ins; 270 del; 44 mod; > > > > Hi all, > > > > could you please review the patch which removes > jdk.testlibrary.JDKToolFinder and JDKToolLauncher and replaces their usages > w/ jdk.test.lib.JDKToolFinder and JDKToolLauncher respectively? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8182404 > > webrev: > http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html > > testing: tier1-3 + :jdk_svc > > > > Thanks, > > -- Igor > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Sep 8 07:50:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 8 Sep 2018 08:50:23 +0100 Subject: RFR(M) : 8182404 : remove jdk.testlibrary.JDKToolFinder and JDKToolLauncher In-Reply-To: References: Message-ID: On 07/09/2018 23:11, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8182404/webrev.00/index.html > I skimmed through the changes and they look okay. One test to check is PatchSystemModules as it looks like /lib/testlibrary can be dropped from its @library tag. -Alan From david.holmes at oracle.com Mon Sep 10 05:51:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Sep 2018 15:51:21 +1000 Subject: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects Message-ID: <91ceaee5-2e8a-4cc8-364a-186a75da4921@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ After the fix for JDK-8209361 where we modified JVM-TI to treat an unresolved CP klass entry to a loaded klass as a resolved CP entry, the listed test starting failing due to finding an extra reference to the test class. As outlined in the bug report this extra reference: 17: instance of java.lang.Class(reflected class=nsk.share.jdi.TestClass1, id=792) actually comes from the class itself. Every classfile has a self-referential entry in the constant pool (this_klass in JVMS 4.1) and that is what we were encountering here. I would argue that such an unresolved reference from a class to itself should never be treated as a "real" reference from a JVM TI perspective, and so we ship skip it - which is what the fix does: - if (klass == NULL) { + if (klass == NULL || klass == ik) { continue; Testing: the test concerned joatc testing of test that failed in 8209361 (TBD) mach5 tiers 1-3 (TBD) jvmti (TBD) As noted testing is still TBD other then actual test but there are technical delays with that so I'll get the RFR out anyway. Thanks, David From dean.long at oracle.com Mon Sep 10 07:31:13 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 10 Sep 2018 00:31:13 -0700 Subject: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <91ceaee5-2e8a-4cc8-364a-186a75da4921@oracle.com> References: <91ceaee5-2e8a-4cc8-364a-186a75da4921@oracle.com> Message-ID: <941445a3-c3de-0106-b687-ead1baa9a6c4@oracle.com> Hi David.? If a class references its own fields or methods, and that code is executed by the interpreter, then we should expect that constant pool entry to be resolved, shouldn't we?? Likewise the compiler will treat it as resolved.? If we treat is as unresolved, we run into the case where we executed compiled code for a method that would have resolved the constant pool entry, but JVMTI says we didn't. Isn't the test in error for assuming no eager resolution? By the way, it looks like we always eagerly resolve this_class for unsafe-anonymous classes. dl On 9/9/18 10:51 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ > > After the fix for JDK-8209361 where we modified JVM-TI to treat an > unresolved CP klass entry to a loaded klass as a resolved CP entry, > the listed test starting failing due to finding an extra reference to > the test class. As outlined in the bug report this extra reference: > > 17: instance of java.lang.Class(reflected > class=nsk.share.jdi.TestClass1, id=792) > > actually comes from the class itself. Every classfile has a > self-referential entry in the constant pool (this_klass in JVMS 4.1) > and that is what we were encountering here. > > I would argue that such an unresolved reference from a class to itself > should never be treated as a "real" reference from a JVM TI > perspective, and so we ship skip it - which is what the fix does: > > - if (klass == NULL) { > + if (klass == NULL || klass == ik) { > ?????????????? continue; > > Testing: the test concerned > ???????? joatc testing of test that failed in 8209361 (TBD) > ???????? mach5 tiers 1-3 (TBD) > ???????? jvmti (TBD) > > As noted testing is still TBD other then actual test but there are > technical delays with that so I'll get the RFR out anyway. > > Thanks, > David From david.holmes at oracle.com Mon Sep 10 08:40:13 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 10 Sep 2018 18:40:13 +1000 Subject: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <941445a3-c3de-0106-b687-ead1baa9a6c4@oracle.com> References: <91ceaee5-2e8a-4cc8-364a-186a75da4921@oracle.com> <941445a3-c3de-0106-b687-ead1baa9a6c4@oracle.com> Message-ID: Hi Dean, On 10/09/2018 5:31 PM, dean.long at oracle.com wrote: > Hi David.? If a class references its own fields or methods, and that > code is executed by the interpreter, then we should expect that constant > pool entry to be resolved, shouldn't we? Yes > Likewise the compiler will > treat it as resolved.? If we treat is as unresolved, we run into the > case where we executed compiled code for a method that would have > resolved the constant pool entry, but JVMTI says we didn't. I don't think the this_klass reference necessarily falls under that categorization though. In an empty class (as used in the test case) there's no bytecode that references any CP index for the current class. It's simply an artifact of the classfile format. > Isn't the test in error for assuming no eager resolution? Hmmm. Yes I suppose that is right. If we did eager resolution then even the this_klass CP entry would have been resolved and the test would have then encountered it from day one. What bothers me is the self-referential nature of this ... and the obscurity of it. I don't think anyone looking at the various heap reference API's would think about a reference-to-self. > By the way, it looks like we always eagerly resolve this_class for > unsafe-anonymous classes. Can you point me at that code please? Thanks, David > dl > > On 9/9/18 10:51 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 >> Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ >> >> After the fix for JDK-8209361 where we modified JVM-TI to treat an >> unresolved CP klass entry to a loaded klass as a resolved CP entry, >> the listed test starting failing due to finding an extra reference to >> the test class. As outlined in the bug report this extra reference: >> >> 17: instance of java.lang.Class(reflected >> class=nsk.share.jdi.TestClass1, id=792) >> >> actually comes from the class itself. Every classfile has a >> self-referential entry in the constant pool (this_klass in JVMS 4.1) >> and that is what we were encountering here. >> >> I would argue that such an unresolved reference from a class to itself >> should never be treated as a "real" reference from a JVM TI >> perspective, and so we ship skip it - which is what the fix does: >> >> - if (klass == NULL) { >> + if (klass == NULL || klass == ik) { >> ?????????????? continue; >> >> Testing: the test concerned >> ???????? joatc testing of test that failed in 8209361 (TBD) >> ???????? mach5 tiers 1-3 (TBD) >> ???????? jvmti (TBD) >> >> As noted testing is still TBD other then actual test but there are >> technical delays with that so I'll get the RFR out anyway. >> >> Thanks, >> David > From dean.long at oracle.com Mon Sep 10 17:33:24 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 10 Sep 2018 10:33:24 -0700 Subject: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: References: <91ceaee5-2e8a-4cc8-364a-186a75da4921@oracle.com> <941445a3-c3de-0106-b687-ead1baa9a6c4@oracle.com> Message-ID: On 9/10/18 1:40 AM, David Holmes wrote: > Hi Dean, > > On 10/09/2018 5:31 PM, dean.long at oracle.com wrote: >> Hi David.? If a class references its own fields or methods, and that >> code is executed by the interpreter, then we should expect that >> constant pool entry to be resolved, shouldn't we? > > Yes > >> Likewise the compiler will treat it as resolved.? If we treat is as >> unresolved, we run into the case where we executed compiled code for >> a method that would have resolved the constant pool entry, but JVMTI >> says we didn't. > > I don't think the this_klass reference necessarily falls under that > categorization though. In an empty class (as used in the test case) > there's no bytecode that references any CP index for the current > class. It's simply an artifact of the classfile format. > >> Isn't the test in error for assuming no eager resolution? > > Hmmm. Yes I suppose that is right. If we did eager resolution then > even the this_klass CP entry would have been resolved and the test > would have then encountered it from day one. > > What bothers me is the self-referential nature of this ... and the > obscurity of it. I don't think anyone looking at the various heap > reference API's would think about a reference-to-self. > Maybe for an empty class, but in general I would expect self references to be considered. >> By the way, it looks like we always eagerly resolve this_class for >> unsafe-anonymous classes. > > Can you point me at that code please? > http://hg.openjdk.java.net/jdk/jdk/file/4e99f412148f/src/hotspot/share/classfile/classFileParser.cpp#l5594 dl > Thanks, > David > >> dl >> >> On 9/9/18 10:51 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 >>> Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ >>> >>> After the fix for JDK-8209361 where we modified JVM-TI to treat an >>> unresolved CP klass entry to a loaded klass as a resolved CP entry, >>> the listed test starting failing due to finding an extra reference >>> to the test class. As outlined in the bug report this extra reference: >>> >>> 17: instance of java.lang.Class(reflected >>> class=nsk.share.jdi.TestClass1, id=792) >>> >>> actually comes from the class itself. Every classfile has a >>> self-referential entry in the constant pool (this_klass in JVMS 4.1) >>> and that is what we were encountering here. >>> >>> I would argue that such an unresolved reference from a class to >>> itself should never be treated as a "real" reference from a JVM TI >>> perspective, and so we ship skip it - which is what the fix does: >>> >>> - if (klass == NULL) { >>> + if (klass == NULL || klass == ik) { >>> ?????????????? continue; >>> >>> Testing: the test concerned >>> ???????? joatc testing of test that failed in 8209361 (TBD) >>> ???????? mach5 tiers 1-3 (TBD) >>> ???????? jvmti (TBD) >>> >>> As noted testing is still TBD other then actual test but there are >>> technical delays with that so I'll get the RFR out anyway. >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Mon Sep 10 21:25:27 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Sep 2018 07:25:27 +1000 Subject: RFR (S) 8210512: vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: References: <91ceaee5-2e8a-4cc8-364a-186a75da4921@oracle.com> <941445a3-c3de-0106-b687-ead1baa9a6c4@oracle.com> Message-ID: <2bfd76d0-2136-f6c5-45f9-5ae4bb98e15d@oracle.com> Hi Dean, I'm withdrawing this RFR and changing to a test-bug. Thanks for the pointer to the anonymous class code. David On 11/09/2018 3:33 AM, dean.long at oracle.com wrote: > On 9/10/18 1:40 AM, David Holmes wrote: >> Hi Dean, >> >> On 10/09/2018 5:31 PM, dean.long at oracle.com wrote: >>> Hi David.? If a class references its own fields or methods, and that >>> code is executed by the interpreter, then we should expect that >>> constant pool entry to be resolved, shouldn't we? >> >> Yes >> >>> Likewise the compiler will treat it as resolved.? If we treat is as >>> unresolved, we run into the case where we executed compiled code for >>> a method that would have resolved the constant pool entry, but JVMTI >>> says we didn't. >> >> I don't think the this_klass reference necessarily falls under that >> categorization though. In an empty class (as used in the test case) >> there's no bytecode that references any CP index for the current >> class. It's simply an artifact of the classfile format. >> >>> Isn't the test in error for assuming no eager resolution? >> >> Hmmm. Yes I suppose that is right. If we did eager resolution then >> even the this_klass CP entry would have been resolved and the test >> would have then encountered it from day one. >> >> What bothers me is the self-referential nature of this ... and the >> obscurity of it. I don't think anyone looking at the various heap >> reference API's would think about a reference-to-self. >> > > Maybe for an empty class, but in general I would expect self references > to be considered. > >>> By the way, it looks like we always eagerly resolve this_class for >>> unsafe-anonymous classes. >> >> Can you point me at that code please? >> > > http://hg.openjdk.java.net/jdk/jdk/file/4e99f412148f/src/hotspot/share/classfile/classFileParser.cpp#l5594 > > > dl > >> Thanks, >> David >> >>> dl >>> >>> On 9/9/18 10:51 PM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 >>>> Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ >>>> >>>> After the fix for JDK-8209361 where we modified JVM-TI to treat an >>>> unresolved CP klass entry to a loaded klass as a resolved CP entry, >>>> the listed test starting failing due to finding an extra reference >>>> to the test class. As outlined in the bug report this extra reference: >>>> >>>> 17: instance of java.lang.Class(reflected >>>> class=nsk.share.jdi.TestClass1, id=792) >>>> >>>> actually comes from the class itself. Every classfile has a >>>> self-referential entry in the constant pool (this_klass in JVMS 4.1) >>>> and that is what we were encountering here. >>>> >>>> I would argue that such an unresolved reference from a class to >>>> itself should never be treated as a "real" reference from a JVM TI >>>> perspective, and so we ship skip it - which is what the fix does: >>>> >>>> - if (klass == NULL) { >>>> + if (klass == NULL || klass == ik) { >>>> ?????????????? continue; >>>> >>>> Testing: the test concerned >>>> ???????? joatc testing of test that failed in 8209361 (TBD) >>>> ???????? mach5 tiers 1-3 (TBD) >>>> ???????? jvmti (TBD) >>>> >>>> As noted testing is still TBD other then actual test but there are >>>> technical delays with that so I'll get the RFR out anyway. >>>> >>>> Thanks, >>>> David >>> > From david.holmes at oracle.com Mon Sep 10 21:31:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Sep 2018 07:31:15 +1000 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects Message-ID: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ After the fix for JDK-8209361 where we modified JVM-TI to treat an unresolved CP klass entry to a loaded klass as a resolved CP entry, the listed test starting failing due to finding an extra reference to the test class. As outlined in the bug report this extra reference: 17: instance of java.lang.Class(reflected class=nsk.share.jdi.TestClass1, id=792) actually comes from the class itself. Every classfile has a self-referential entry in the constant pool (this_class in JVMS 4.1) and that is what we were encountering here. For the empty class used in the test this reference remains unresolved, but in general it could be resolved and would otherwise be found. So the fix for the test is to now expect to always find this self-reference. Thanks, David From serguei.spitsyn at oracle.com Mon Sep 10 21:58:41 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 10 Sep 2018 14:58:41 -0700 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> References: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> Message-ID: <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> Hi David, It looks good to me. Thank you for taking care about it! Thanks, Serguei On 9/10/18 14:31, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ > > After the fix for JDK-8209361 where we modified JVM-TI to treat an > unresolved CP klass entry to a loaded klass as a resolved CP entry, > the listed test starting failing due to finding an extra reference to > the test class. As outlined in the bug report this extra reference: > > 17: instance of java.lang.Class(reflected > class=nsk.share.jdi.TestClass1, id=792) > > actually comes from the class itself. Every classfile has a > self-referential entry in the constant pool (this_class in JVMS 4.1) > and that is what we were encountering here. > > For the empty class used in the test this reference remains > unresolved, but in general it could be resolved and would otherwise be > found. So the fix for the test is to now expect to always find this > self-reference. > > Thanks, > David From jcbeyler at google.com Mon Sep 10 22:10:45 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 10 Sep 2018 15:10:45 -0700 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> References: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> Message-ID: Hi David, Looks good to me (I'm not a reviewer but wanted to piggy-back and say I actually learnt quite a bit with the conversation on the original webrev). Thanks! Jc On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi David, > > It looks good to me. > Thank you for taking care about it! > > Thanks, > Serguei > > > On 9/10/18 14:31, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 > > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ > > > > After the fix for JDK-8209361 where we modified JVM-TI to treat an > > unresolved CP klass entry to a loaded klass as a resolved CP entry, > > the listed test starting failing due to finding an extra reference to > > the test class. As outlined in the bug report this extra reference: > > > > 17: instance of java.lang.Class(reflected > > class=nsk.share.jdi.TestClass1, id=792) > > > > actually comes from the class itself. Every classfile has a > > self-referential entry in the constant pool (this_class in JVMS 4.1) > > and that is what we were encountering here. > > > > For the empty class used in the test this reference remains > > unresolved, but in general it could be resolved and would otherwise be > > found. So the fix for the test is to now expect to always find this > > self-reference. > > > > Thanks, > > David > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Sep 10 22:59:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Sep 2018 08:59:34 +1000 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: References: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> Message-ID: <174bba1f-0679-db78-32d4-c139457436c3@oracle.com> Thanks for the reviews Serguei and JC. On 11/09/2018 8:10 AM, JC Beyler wrote: > Hi David, > > Looks good to me (I'm not a reviewer but wanted to piggy-back and say I > actually learnt quite a bit with the conversation on the original webrev). :) I've learnt a few things with these changes too. Cheers, David > Thanks! > Jc > > On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com > > wrote: > > Hi David, > > It looks good to me. > Thank you for taking care about it! > > Thanks, > Serguei > > > On 9/10/18 14:31, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 > > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ > > > > > After the fix for JDK-8209361 where we modified JVM-TI to treat an > > unresolved CP klass entry to a loaded klass as a resolved CP entry, > > the listed test starting failing due to finding an extra > reference to > > the test class. As outlined in the bug report this extra reference: > > > > 17: instance of java.lang.Class(reflected > > class=nsk.share.jdi.TestClass1, id=792) > > > > actually comes from the class itself. Every classfile has a > > self-referential entry in the constant pool (this_class in JVMS 4.1) > > and that is what we were encountering here. > > > > For the empty class used in the test this reference remains > > unresolved, but in general it could be resolved and would > otherwise be > > found. So the fix for the test is to now expect to always find this > > self-reference. > > > > Thanks, > > David > > > > -- > > Thanks, > Jc From jcbeyler at google.com Mon Sep 10 23:13:46 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 10 Sep 2018 16:13:46 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> Message-ID: Hi Alex, Done! Anyone else motivated in looking at part 1 out of 4 to remove all JNI_ENV* from our vmTestbase tests? Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 Thanks! Jc On Fri, Sep 7, 2018 at 2:07 PM Alex Menkov wrote: > Hi Jc, > > The fix looks good. > The only note: > > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.cpp > > contains double jvmti initialization: > - res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), > - JVMTI_VERSION_1_1); > + res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); > if (res != JNI_OK || jvmti == NULL) { > printf("Wrong result of a valid call to GetEnv!\n"); > return JNI_ERR; > } > > - res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), > - JVMTI_VERSION_1_1); > + res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); > if (res != JNI_OK || jvmti == NULL) { > printf("Wrong result of a valid call to GetEnv!\n"); > return JNI_ERR; > } > Could you please remove one of them. > > --alex > > On 09/07/2018 12:22, JC Beyler wrote: > > Hi Alex, > > > > Sounds good to me, I'll aim between 40~50 files then :) > > > > Here is the jvmti/A-N* remaining refactoring of the JNI_ENV* / > > JVMTI_ENV* macros: > > > > I have updated the bug to reflect this: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > Thanks again! > > Jc > > > > > > On Fri, Sep 7, 2018 at 11:51 AM Alex Menkov > > wrote: > > > > I think ~40-50 files per fix is my maximum :) > > > > --alex > > > > On 09/07/2018 11:37, JC Beyler wrote: > > > Sounds good to me, would you prefer it in 4 webrevs of 1k > > changes? Or 2 > > > webrevs of 2k changes? > > > > > > I can do either easily, so just let me know; your job as the > > reviewer is > > > harder for these :) > > > Jc > > > > > > On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov > > > > > > >> wrote: > > > > > > Hi Jc, > > > > > > I'd prefer to see the fix splitted to smaller parts. > > > The changes are quite simple, but it's just too many files, > > so it's > > > impossible (at least for me) to review them accurately. > > > > > > --alex > > > > > > On 09/07/2018 10:53, JC Beyler wrote: > > > > Hi all, > > > > > > > > I'm taking the risk to perhaps do something too huge but > > as it is > > > the > > > > same as the previous ones (and the last one!): > > > > > > > > It's 4k of changes, for that I apologize. I can divide it > > up in 2/3 > > > > parts again if you want or we can just do it in one go > > since now > > > some > > > > reviewers know what to expect. There still is a bit of > > > refactoring to > > > > the vmTestbase but this will in essence finish: > > > > - Removing the JNI_ENV* and JVMTI_ENV* macros for the > > vmTestbase > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > > > > > Thanks for your reviews and let me know if you would > > prefer me to > > > cut it > > > > up like I did the Get[A-F] & Get[G-Z] ones, > > > > Jc > > > > > > > > Ps: for the curious, then we can start cleaning up the > native > > > code a bit > > > > more sanely (example: JDK-8191519) and there will be one > > more webrev > > > > removing #ifdef cplusplus lingering in the vmTestbase > > (JDK-8210481). > > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Sep 10 23:16:16 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 10 Sep 2018 16:16:16 -0700 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <174bba1f-0679-db78-32d4-c139457436c3@oracle.com> References: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> <174bba1f-0679-db78-32d4-c139457436c3@oracle.com> Message-ID: <9080d59a-35ec-8fb7-252c-d5b47696ffef@oracle.com> I also tried to learn from your email exchange with Dean L. Thanks, Serguei On 9/10/18 15:59, David Holmes wrote: > Thanks for the reviews Serguei and JC. > > On 11/09/2018 8:10 AM, JC Beyler wrote: >> Hi David, >> >> Looks good to me (I'm not a reviewer but wanted to piggy-back and say >> I actually learnt quite a bit with the conversation on the original >> webrev). > > :) I've learnt a few things with these changes too. > > Cheers, > David > >> Thanks! >> Jc >> >> On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com >> > > wrote: >> >> ??? Hi David, >> >> ??? It looks good to me. >> ??? Thank you for taking care about it! >> >> ??? Thanks, >> ??? Serguei >> >> >> ??? On 9/10/18 14:31, David Holmes wrote: >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 >> ???? > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ >> >> ???? > >> ???? > After the fix for JDK-8209361 where we modified JVM-TI to >> treat an >> ???? > unresolved CP klass entry to a loaded klass as a resolved CP >> entry, >> ???? > the listed test starting failing due to finding an extra >> ??? reference to >> ???? > the test class. As outlined in the bug report this extra >> reference: >> ???? > >> ???? > 17: instance of java.lang.Class(reflected >> ???? > class=nsk.share.jdi.TestClass1, id=792) >> ???? > >> ???? > actually comes from the class itself. Every classfile has a >> ???? > self-referential entry in the constant pool (this_class in >> JVMS 4.1) >> ???? > and that is what we were encountering here. >> ???? > >> ???? > For the empty class used in the test this reference remains >> ???? > unresolved, but in general it could be resolved and would >> ??? otherwise be >> ???? > found. So the fix for the test is to now expect to always find >> this >> ???? > self-reference. >> ???? > >> ???? > Thanks, >> ???? > David >> >> >> >> -- >> >> Thanks, >> Jc From dean.long at oracle.com Mon Sep 10 23:25:23 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 10 Sep 2018 16:25:23 -0700 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <9080d59a-35ec-8fb7-252c-d5b47696ffef@oracle.com> References: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> <174bba1f-0679-db78-32d4-c139457436c3@oracle.com> <9080d59a-35ec-8fb7-252c-d5b47696ffef@oracle.com> Message-ID: <64ae6cab-de50-097e-522a-7ae347832a0f@oracle.com> +1 for this change +1 for learning new things :-) dl On 9/10/18 4:16 PM, serguei.spitsyn at oracle.com wrote: > I also tried to learn from your email exchange with Dean L. > > Thanks, > Serguei > > > On 9/10/18 15:59, David Holmes wrote: >> Thanks for the reviews Serguei and JC. >> >> On 11/09/2018 8:10 AM, JC Beyler wrote: >>> Hi David, >>> >>> Looks good to me (I'm not a reviewer but wanted to piggy-back and >>> say I actually learnt quite a bit with the conversation on the >>> original webrev). >> >> :) I've learnt a few things with these changes too. >> >> Cheers, >> David >> >>> Thanks! >>> Jc >>> >>> On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com >>> >> > wrote: >>> >>> ??? Hi David, >>> >>> ??? It looks good to me. >>> ??? Thank you for taking care about it! >>> >>> ??? Thanks, >>> ??? Serguei >>> >>> >>> ??? On 9/10/18 14:31, David Holmes wrote: >>> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 >>> ???? > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ >>> >>> ???? > >>> ???? > After the fix for JDK-8209361 where we modified JVM-TI to >>> treat an >>> ???? > unresolved CP klass entry to a loaded klass as a resolved CP >>> entry, >>> ???? > the listed test starting failing due to finding an extra >>> ??? reference to >>> ???? > the test class. As outlined in the bug report this extra >>> reference: >>> ???? > >>> ???? > 17: instance of java.lang.Class(reflected >>> ???? > class=nsk.share.jdi.TestClass1, id=792) >>> ???? > >>> ???? > actually comes from the class itself. Every classfile has a >>> ???? > self-referential entry in the constant pool (this_class in >>> JVMS 4.1) >>> ???? > and that is what we were encountering here. >>> ???? > >>> ???? > For the empty class used in the test this reference remains >>> ???? > unresolved, but in general it could be resolved and would >>> ??? otherwise be >>> ???? > found. So the fix for the test is to now expect to always >>> find this >>> ???? > self-reference. >>> ???? > >>> ???? > Thanks, >>> ???? > David >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc > From alexey.menkov at oracle.com Mon Sep 10 23:40:04 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 10 Sep 2018 16:40:04 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests Message-ID: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> Hi, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8210560 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.01/ New class (ClassTransformer) was developed to implement simple class transformer for class redefinition (the same functionality as implemented by ShellScaffold.sh). Both setBreakpoint and redefineClass require source file name, so JdbTest class was updated to accept it as ctor argument and use by corresponding methods. --alex From david.holmes at oracle.com Tue Sep 11 01:51:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Sep 2018 11:51:15 +1000 Subject: RFR: (S) 8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects In-Reply-To: <64ae6cab-de50-097e-522a-7ae347832a0f@oracle.com> References: <48fa0393-fc6f-6442-781f-64d90ccf0b9c@oracle.com> <3b6520ef-e546-5137-8706-c13f3ffe047e@oracle.com> <174bba1f-0679-db78-32d4-c139457436c3@oracle.com> <9080d59a-35ec-8fb7-252c-d5b47696ffef@oracle.com> <64ae6cab-de50-097e-522a-7ae347832a0f@oracle.com> Message-ID: <7ffee8c3-64ca-1f0a-43e1-4f7203c2c005@oracle.com> Thanks Dean. Sorry I'd already pushed it. David On 11/09/2018 9:25 AM, dean.long at oracle.com wrote: > +1 for this change > +1 for learning new things :-) > > dl > > On 9/10/18 4:16 PM, serguei.spitsyn at oracle.com wrote: >> I also tried to learn from your email exchange with Dean L. >> >> Thanks, >> Serguei >> >> >> On 9/10/18 15:59, David Holmes wrote: >>> Thanks for the reviews Serguei and JC. >>> >>> On 11/09/2018 8:10 AM, JC Beyler wrote: >>>> Hi David, >>>> >>>> Looks good to me (I'm not a reviewer but wanted to piggy-back and >>>> say I actually learnt quite a bit with the conversation on the >>>> original webrev). >>> >>> :) I've learnt a few things with these changes too. >>> >>> Cheers, >>> David >>> >>>> Thanks! >>>> Jc >>>> >>>> On Mon, Sep 10, 2018 at 2:59 PM serguei.spitsyn at oracle.com >>>> >>> > wrote: >>>> >>>> ??? Hi David, >>>> >>>> ??? It looks good to me. >>>> ??? Thank you for taking care about it! >>>> >>>> ??? Thanks, >>>> ??? Serguei >>>> >>>> >>>> ??? On 9/10/18 14:31, David Holmes wrote: >>>> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210512 >>>> ???? > Webrev: http://cr.openjdk.java.net/~dholmes/8210512/webrev/ >>>> >>>> ???? > >>>> ???? > After the fix for JDK-8209361 where we modified JVM-TI to >>>> treat an >>>> ???? > unresolved CP klass entry to a loaded klass as a resolved CP >>>> entry, >>>> ???? > the listed test starting failing due to finding an extra >>>> ??? reference to >>>> ???? > the test class. As outlined in the bug report this extra >>>> reference: >>>> ???? > >>>> ???? > 17: instance of java.lang.Class(reflected >>>> ???? > class=nsk.share.jdi.TestClass1, id=792) >>>> ???? > >>>> ???? > actually comes from the class itself. Every classfile has a >>>> ???? > self-referential entry in the constant pool (this_class in >>>> JVMS 4.1) >>>> ???? > and that is what we were encountering here. >>>> ???? > >>>> ???? > For the empty class used in the test this reference remains >>>> ???? > unresolved, but in general it could be resolved and would >>>> ??? otherwise be >>>> ???? > found. So the fix for the test is to now expect to always >>>> find this >>>> ???? > self-reference. >>>> ???? > >>>> ???? > Thanks, >>>> ???? > David >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >> > From jcbeyler at google.com Tue Sep 11 04:00:21 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 10 Sep 2018 21:00:21 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests In-Reply-To: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> References: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> Message-ID: Hi Alex, I was looking at this and I have a few nits and questions: - I saw two spots in the patch that had weird spaces: test/jdk/com/sun/jdi/RedefineG.java + super( DEBUGGEE_CLASS, + "RedefineG.java"); - Then test/jdk/com/sun/jdi/RedefineImplementor.java + super( RedefineImplementorTarg.class.getName(), + "RedefineImplementor.java"); - My only question is should we not be worried or care if both test/jdk/com/sun/jdi/lib/jdb/JdbTest.java and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java have now ways that could provoke NPEs? Should the code not try to throw an exception and say: careful, you called this but didn't call that first? It would make misuse of the class easier to debug when writing new tests. (Example being: calling redefineClass but not using the right constructor) I know it is for testing only but if we start writing new tests, it could be useful to be a bit defensive? Apart from that, looked good to me. Jc On Mon, Sep 10, 2018 at 4:40 PM Alex Menkov wrote: > Hi, > > Please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8210560 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.01/ > > New class (ClassTransformer) was developed to implement simple class > transformer for class redefinition (the same functionality as > implemented by ShellScaffold.sh). > > Both setBreakpoint and redefineClass require source file name, so > JdbTest class was updated to accept it as ctor argument and use by > corresponding methods. > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Sep 11 05:04:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Sep 2018 15:04:33 +1000 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> Message-ID: Hi JC, I skimmed through this and it seems fine to me. Thanks, David On 11/09/2018 9:13 AM, JC Beyler wrote: > Hi Alex, > > Done! Anyone else motivated in looking at part 1 out of 4 to remove all > JNI_ENV* from our vmTestbase tests? > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > Thanks! > Jc > > On Fri, Sep 7, 2018 at 2:07 PM Alex Menkov > wrote: > > Hi Jc, > > The fix looks good. > The only note: > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.cpp > > contains double jvmti initialization: > -? ? res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), > -? ? ? ? JVMTI_VERSION_1_1); > +? ? res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); > ? ? ? if (res != JNI_OK || jvmti == NULL) { > ? ? ? ? ? printf("Wrong result of a valid call to GetEnv!\n"); > ? ? ? ? ? return JNI_ERR; > ? ? ? } > > -? ? res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &jvmti), > -? ? ? ? JVMTI_VERSION_1_1); > +? ? res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); > ? ? ? if (res != JNI_OK || jvmti == NULL) { > ? ? ? ? ? printf("Wrong result of a valid call to GetEnv!\n"); > ? ? ? ? ? return JNI_ERR; > ? ? ? } > Could you please remove one of them. > > --alex > > On 09/07/2018 12:22, JC Beyler wrote: > > Hi Alex, > > > > Sounds good to me, I'll aim between 40~50 files then :) > > > > Here is the jvmti/A-N* remaining refactoring of the JNI_ENV* / > > JVMTI_ENV* macros: > > > > I have updated the bug to reflect this: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > Thanks again! > > Jc > > > > > > On Fri, Sep 7, 2018 at 11:51 AM Alex Menkov > > > >> wrote: > > > >? ? ?I think ~40-50 files per fix is my maximum :) > > > >? ? ?--alex > > > >? ? ?On 09/07/2018 11:37, JC Beyler wrote: > >? ? ? > Sounds good to me, would you prefer it in 4 webrevs of 1k > >? ? ?changes? Or 2 > >? ? ? > webrevs of 2k changes? > >? ? ? > > >? ? ? > I can do either easily, so just let me know; your job as the > >? ? ?reviewer is > >? ? ? > harder for these :) > >? ? ? > Jc > >? ? ? > > >? ? ? > On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov > >? ? ? > > > >? ? ? > > >? ? ? >>> wrote: > >? ? ? > > >? ? ? >? ? ?Hi Jc, > >? ? ? > > >? ? ? >? ? ?I'd prefer to see the fix splitted to smaller parts. > >? ? ? >? ? ?The changes are quite simple, but it's just too many > files, > >? ? ?so it's > >? ? ? >? ? ?impossible (at least for me) to review them accurately. > >? ? ? > > >? ? ? >? ? ?--alex > >? ? ? > > >? ? ? >? ? ?On 09/07/2018 10:53, JC Beyler wrote: > >? ? ? >? ? ? > Hi all, > >? ? ? >? ? ? > > >? ? ? >? ? ? > I'm taking the risk to perhaps do something too > huge but > >? ? ?as it is > >? ? ? >? ? ?the > >? ? ? >? ? ? > same as the previous ones (and the last one!): > >? ? ? >? ? ? > > >? ? ? >? ? ? > It's 4k of changes, for that I apologize. I can > divide it > >? ? ?up in 2/3 > >? ? ? >? ? ? > parts again if you want or we can just do it in one go > >? ? ?since now > >? ? ? >? ? ?some > >? ? ? >? ? ? > reviewers know what to expect. There still is a bit of > >? ? ? >? ? ?refactoring to > >? ? ? >? ? ? > the vmTestbase but this will in essence finish: > >? ? ? >? ? ? >? ? - Removing the JNI_ENV* and JVMTI_ENV* macros > for the > >? ? ?vmTestbase > >? ? ? >? ? ? > > >? ? ? >? ? ? > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > > >? ? ? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > >? ? ? >? ? ? > > >? ? ? >? ? ? > Thanks for your reviews and let me know if you would > >? ? ?prefer me to > >? ? ? >? ? ?cut it > >? ? ? >? ? ? > up like I did the Get[A-F] & Get[G-Z] ones, > >? ? ? >? ? ? > Jc > >? ? ? >? ? ? > > >? ? ? >? ? ? > Ps: for the curious, then we can start cleaning up > the native > >? ? ? >? ? ?code a bit > >? ? ? >? ? ? > more sanely (example: JDK-8191519) and there will > be one > >? ? ?more webrev > >? ? ? >? ? ? > removing #ifdef cplusplus lingering in the vmTestbase > >? ? ?(JDK-8210481). > >? ? ? >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > -- > >? ? ? > > >? ? ? > Thanks, > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From jcbeyler at google.com Tue Sep 11 14:43:26 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 11 Sep 2018 07:43:26 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> Message-ID: Thanks both for the reviews :) Jc On Mon, Sep 10, 2018 at 10:04 PM David Holmes wrote: > Hi JC, > > I skimmed through this and it seems fine to me. > > Thanks, > David > > On 11/09/2018 9:13 AM, JC Beyler wrote: > > Hi Alex, > > > > Done! Anyone else motivated in looking at part 1 out of 4 to remove all > > JNI_ENV* from our vmTestbase tests? > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > Thanks! > > Jc > > > > On Fri, Sep 7, 2018 at 2:07 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > The fix looks good. > > The only note: > > > > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/IsFieldSynthetic/isfldsin003/isfldsin003.cpp > > > > contains double jvmti initialization: > > - res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) > &jvmti), > > - JVMTI_VERSION_1_1); > > + res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); > > if (res != JNI_OK || jvmti == NULL) { > > printf("Wrong result of a valid call to GetEnv!\n"); > > return JNI_ERR; > > } > > > > - res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) > &jvmti), > > - JVMTI_VERSION_1_1); > > + res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_1_1); > > if (res != JNI_OK || jvmti == NULL) { > > printf("Wrong result of a valid call to GetEnv!\n"); > > return JNI_ERR; > > } > > Could you please remove one of them. > > > > --alex > > > > On 09/07/2018 12:22, JC Beyler wrote: > > > Hi Alex, > > > > > > Sounds good to me, I'll aim between 40~50 files then :) > > > > > > Here is the jvmti/A-N* remaining refactoring of the JNI_ENV* / > > > JVMTI_ENV* macros: > > > > > > I have updated the bug to reflect this: > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.01/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > > > Thanks again! > > > Jc > > > > > > > > > On Fri, Sep 7, 2018 at 11:51 AM Alex Menkov > > > > > > >> wrote: > > > > > > I think ~40-50 files per fix is my maximum :) > > > > > > --alex > > > > > > On 09/07/2018 11:37, JC Beyler wrote: > > > > Sounds good to me, would you prefer it in 4 webrevs of 1k > > > changes? Or 2 > > > > webrevs of 2k changes? > > > > > > > > I can do either easily, so just let me know; your job as > the > > > reviewer is > > > > harder for these :) > > > > Jc > > > > > > > > On Fri, Sep 7, 2018 at 11:34 AM Alex Menkov > > > > > > > > > > > > > > > >>> wrote: > > > > > > > > Hi Jc, > > > > > > > > I'd prefer to see the fix splitted to smaller parts. > > > > The changes are quite simple, but it's just too many > > files, > > > so it's > > > > impossible (at least for me) to review them accurately. > > > > > > > > --alex > > > > > > > > On 09/07/2018 10:53, JC Beyler wrote: > > > > > Hi all, > > > > > > > > > > I'm taking the risk to perhaps do something too > > huge but > > > as it is > > > > the > > > > > same as the previous ones (and the last one!): > > > > > > > > > > It's 4k of changes, for that I apologize. I can > > divide it > > > up in 2/3 > > > > > parts again if you want or we can just do it in one > go > > > since now > > > > some > > > > > reviewers know what to expect. There still is a bit > of > > > > refactoring to > > > > > the vmTestbase but this will in essence finish: > > > > > - Removing the JNI_ENV* and JVMTI_ENV* macros > > for the > > > vmTestbase > > > > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~jcbeyler/8210385/webrev.00/ > > > > > > > > > > > > > > > > > > > > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210385 > > > > > > > > > > Thanks for your reviews and let me know if you would > > > prefer me to > > > > cut it > > > > > up like I did the Get[A-F] & Get[G-Z] ones, > > > > > Jc > > > > > > > > > > Ps: for the curious, then we can start cleaning up > > the native > > > > code a bit > > > > > more sanely (example: JDK-8191519) and there will > > be one > > > more webrev > > > > > removing #ifdef cplusplus lingering in the > vmTestbase > > > (JDK-8210481). > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Sep 11 17:54:37 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 11 Sep 2018 10:54:37 -0700 Subject: RFR (M) 8210593: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[N-R] tests Message-ID: Hi all, I am continuing the clean up of the testbase with the next batch, I know this is getting repetitive but bear with me please. Here is another one with 50 file changes and ~1000 line changes. Webrev: http://cr.openjdk.java.net/~jcbeyler/8210593/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210593 This passes testing for the changed tests on my dev machine. Thanks for your reviews, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Tue Sep 11 19:28:15 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 11 Sep 2018 12:28:15 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests In-Reply-To: References: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> Message-ID: Hi Jc, Thank you for review. Updated webrev (fixed both issue noted): http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/ --alex On 09/10/2018 21:00, JC Beyler wrote: > Hi Alex, > > I was looking at this and I have a few nits and questions: > - I saw two spots in the patch that had weird spaces: > test/jdk/com/sun/jdi/RedefineG.java > > + super( DEBUGGEE_CLASS, > + "RedefineG.java"); > > - Then test/jdk/com/sun/jdi/RedefineImplementor.java > > + super( RedefineImplementorTarg.class.getName(), > + "RedefineImplementor.java"); > > > - My only question is should we not be worried or care if both test/jdk/com/sun/jdi/lib/jdb/JdbTest.java and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java have now ways that could provoke NPEs? Should the code not try to throw an exception and say: careful, you called this but didn't call that first? It would make misuse of the class easier to debug when writing new tests. > > (Example being: calling redefineClass but not using the right constructor) > > I know it is for testing only but if we start writing new tests, it could be useful to be a bit defensive? > > > Apart from that, looked good to me. > > Jc > > > > On Mon, Sep 10, 2018 at 4:40 PM Alex Menkov > wrote: > > Hi, > > Please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8210560 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.01/ > > > New class (ClassTransformer) was developed to implement simple class > transformer for class redefinition (the same functionality as > implemented by ShellScaffold.sh). > > Both setBreakpoint and redefineClass require source file name, so > JdbTest class was updated to accept it as ctor argument and use by > corresponding methods. > > --alex > > > > -- > > Thanks, > Jc From jcbeyler at google.com Tue Sep 11 20:18:58 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 11 Sep 2018 13:18:58 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests In-Reply-To: References: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> Message-ID: Hi Alex, Looks great to me, thanks for addressing those two points! Jc On Tue, Sep 11, 2018 at 12:28 PM Alex Menkov wrote: > Hi Jc, > > Thank you for review. > Updated webrev (fixed both issue noted): > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/ > > --alex > > On 09/10/2018 21:00, JC Beyler wrote: > > Hi Alex, > > > > I was looking at this and I have a few nits and questions: > > - I saw two spots in the patch that had weird spaces: > > test/jdk/com/sun/jdi/RedefineG.java > > > > + super( DEBUGGEE_CLASS, > > + "RedefineG.java"); > > > > - Then test/jdk/com/sun/jdi/RedefineImplementor.java > > > > + super( RedefineImplementorTarg.class.getName(), > > + "RedefineImplementor.java"); > > > > > > - My only question is should we not be worried or care if both > test/jdk/com/sun/jdi/lib/jdb/JdbTest.java and > test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java have now ways that could > provoke NPEs? Should the code not try to throw an exception and say: > careful, you called this but didn't call that first? It would make misuse > of the class easier to debug when writing new tests. > > > > (Example being: calling redefineClass but not using the right > constructor) > > > > I know it is for testing only but if we start writing new tests, it > could be useful to be a bit defensive? > > > > > > Apart from that, looked good to me. > > > > Jc > > > > > > > > On Mon, Sep 10, 2018 at 4:40 PM Alex Menkov > > wrote: > > > > Hi, > > > > Please review a fix for > > https://bugs.openjdk.java.net/browse/JDK-8210560 > > webrev: > > > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.01/ > > < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/redefineClasses1/webrev.01/> > > > > New class (ClassTransformer) was developed to implement simple class > > transformer for class redefinition (the same functionality as > > implemented by ShellScaffold.sh). > > > > Both setBreakpoint and redefineClass require source file name, so > > JdbTest class was updated to accept it as ctor argument and use by > > corresponding methods. > > > > --alex > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Tue Sep 11 21:23:19 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 11 Sep 2018 14:23:19 -0700 Subject: RFR (M) 8210593: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[N-R] tests In-Reply-To: References: Message-ID: Hi Jc, Looks good. --alex On 09/11/2018 10:54, JC Beyler wrote: > Hi all, > > I am continuing the clean up of the testbase with the next batch, I know > this is getting repetitive but bear?with me please. > > Here is another one with 50 file changes and ~1000 line changes. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210593/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210593 > > This passes testing for the changed tests on my dev machine. > > Thanks for your reviews, > Jc From brent.christian at oracle.com Tue Sep 11 22:41:18 2018 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 11 Sep 2018 15:41:18 -0700 Subject: RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX Message-ID: Hi, Please review this change to how the platform encoding is determined on Mac when loading agents. Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/ Additional details in the bug report: https://bugs.openjdk.java.net/browse/JDK-8072130 Some background: Since JDK 8, if MacOS reports an encoding of US-ASCII, but no encoding hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1]. (This allowed apps launched via double-clicked jar to display files correctly for non-ASCII languages). A similar encoding tweak was not made in the code path used for loading agents. This can come into play when an agent jar includes a Boot-Class-Path entry containing non-ASCII characters. iconv() gets setup to convert UTF-8 to US-ASCII[2], but will fail when encountering extended characters in the entry, so the path in question is not added to the bootclasspath[3]. This will likely lead to a ClassNotFoundException. When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default encoding of UTF-8 (per 8011194) and creates Agent.jar with a Boot-Class-Path that includes non-ASCII characters. But the Boot-Class-Path entry gets skipped when loading Agent.jar, so the AgentSupport class can't be found. I propose this be fixed by adding the same UTF-8 encoding adjustment on MacOS from 8011194 to the agent loading code path. An additional note: This bug was challenging to reproduce, in large part because the 8011194 code checks for an absent env var (getenv() == null), but not for env vars with a blank/empty string value (getenv() == ""), so the test environment had to be setup in a specific way (e.g. 'unset LANG' vs 'export LANG=') to reproduce this bug. So I'd like to update the code to also check for empty string. I also added a couple small improvements to the test. Thanks! -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8011194 2. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 3. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873 From david.holmes at oracle.com Wed Sep 12 03:35:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Sep 2018 13:35:22 +1000 Subject: RFR (M) 8210593: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[N-R] tests In-Reply-To: References: Message-ID: <2765290c-3317-fb96-4353-08d71b98a499@oracle.com> Looks good. Thanks, David On 12/09/2018 3:54 AM, JC Beyler wrote: > Hi all, > > I am continuing the clean up of the testbase with the next batch, I know > this is getting repetitive but bear?with me please. > > Here is another one with 50 file changes and ~1000 line changes. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210593/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210593 > > This passes testing for the changed tests on my dev machine. > > Thanks for your reviews, > Jc From serguei.spitsyn at oracle.com Wed Sep 12 05:15:33 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Sep 2018 22:15:33 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests In-Reply-To: References: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> Message-ID: <798d3e43-261b-f4fb-9ede-cd0192bd2857@oracle.com> An HTML attachment was scrubbed... URL: From per.liden at oracle.com Wed Sep 12 08:24:30 2018 From: per.liden at oracle.com (Per Liden) Date: Wed, 12 Sep 2018 10:24:30 +0200 Subject: RFR: 8209163: SA: Show Object Histogram asserts with ZGC Message-ID: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> This patch avoids an assertion, and instead prints a warning, when trying to show the "Object Histogram" when using ZGC. I also had to add a call to heapIterationFractionUpdate() so that the update progress frame is properly created, even when there are not heap regions to walk over. Without this, you only get a call to heapIterationCompleted(), with a null frame, which throws a NullPointerException. Always making a call to heapIterationFractionUpdate(0.0) in the prologue avoids this by making sure we always created the frame, even if no more fraction updates will happen. Bug: https://bugs.openjdk.java.net/browse/JDK-8209163 Webrev: http://cr.openjdk.java.net/~pliden/8209163/webrev.0 /Per From gary.adams at oracle.com Wed Sep 12 14:27:46 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 12 Sep 2018 10:27:46 -0400 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" Message-ID: <5B992262.5000509@oracle.com> The print statements in the locals002 test have been observed to interfere with the output from commands, replies and prompts used in the synchronization of operations between the debugger and debuggee. This change will remove the print statements. A follow up bug will be filed for longer term investigation of the character at a time output which leaves a larger window for the output interruption that occurs. Issue: https://bugs.openjdk.java.net/browse/JDK-8208468 Proposed update: diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java @@ -81,7 +81,7 @@ int[] arrVar ) { - System.out.println("Arguments but no locals"); // locals002.BREAKPOINT_LINE1 + int x = 3; // locals002.BREAKPOINT_LINE1 } static void allKindsOfLocals() { @@ -97,6 +97,6 @@ int[] arrVar = new int[5]; for (int j = 0; j < 5 ; j++) arrVar[j] = j; - System.out.println("Locals but no arguments"); // locals002.BREAKPOINT_LINE2 + int x = 4; // locals002.BREAKPOINT_LINE2 } } From gary.adams at oracle.com Wed Sep 12 15:20:47 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 12 Sep 2018 11:20:47 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B902B70.8080700@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> <5B90251D.600@oracle.com> <91580473-07d0-84bf-18c5-3e92b38b00cd@oracle.com> <5B902B70.8080700@oracle.com> Message-ID: <5B992ECF.4060000@oracle.com> Here's the updated webrev to avoid the NPE, but still fail the test with more information about the premature completed threads. Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 Webrev: http://cr.openjdk.java.net/~gadams/8210252/webrev.00/ On 9/5/18, 3:16 PM, Gary Adams wrote: > After a quick local check of finishedThreads =1, > I moved the check til after the full list of threads is checked, > rather than repeating the stderr failure after each entry was > processed. > > I also implemented a resumeVM() in TestScaffold and called it before > dumpThreads(). That did not fail locally, so I submitted a mach5 job > so I can > run more tests in batches. > > ... > > On 9/5/18, 2:56 PM, Chris Plummer wrote: >> I was thinking something like the resume() call. At the very least >> just try setting finishedThreads = 1 to exercise the error handling. >> >> Chris >> >> On 9/5/18 11:49 AM, Gary Adams wrote: >>> I had tried sleeping after each entry in dumpThreads was checked, >>> but the >>> failure never occurred. >>> >>> I had tried using mach5 --jvm-args to set UseZGC, but that never >>> failed. >>> >>> Could attempt a resume() before calling dumpThreads() - haven't >>> tried that , yet. >>> >>> On 9/5/18, 2:31 PM, Chris Plummer wrote: >>>> Ok. Have you found a way to test your changes? Maybe just force or >>>> simulate a failure somehow. >>>> >>>> Chris >>>> >>>> On 9/5/18 11:26 AM, Gary Adams wrote: >>>>> If we go ahead with this proposed fix, the next time it fails >>>>> we will have more information about the other threads >>>>> captured in the log. >>>>> >>>>> One last observation, the test that failed was running with UseZGC. >>>>> Not sure how that might impact this particular test. >>>>> >>>>> On 9/5/18, 2:07 PM, Chris Plummer wrote: >>>>>> >>>>>> Hi Gary, >>>>>> >>>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>> >>>>>> The failure explanation seems to hinge on this, but I don't see >>>>>> how this can happen. What is resuming DebugThreadTarg? Only the >>>>>> call to listenUntilVMDisconnect() should be doing this, and we >>>>>> aren't even getting that far. The only thing I can think of is >>>>>> due to some other issue (maybe host out of memory so process was >>>>>> killed off), the DebugThreadTarg process has exited unexpectedly. >>>>>> In this case I guess the fix you have is appropriate defensive >>>>>> programming, causing the test to fail when this happens, but >>>>>> still won't explain why it happens and also won't prevent future >>>>>> failures of this test. Also, this type of Debuggee early exit >>>>>> problem could happen with other tests too. I'm leaning towards >>>>>> just closing this bug as CNR. I don't think we want to be writing >>>>>> our tests to defend against random system related failures, >>>>>> especially when the end result is still going to be a test >>>>>> failure that we don't fully understand. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/5/18 7:33 AM, Gary Adams wrote: >>>>>>> The DebuggerThreadTest ensures it is in sync >>>>>>> at the beginning of RunTests with a breakpoint event >>>>>>> in DebuggerThreadTarg ready() method. >>>>>>> >>>>>>> The DebuggerThreadTest then continues with >>>>>>> dumpThreads() and listenUntilVMDisconnect() >>>>>>> completes. >>>>>>> >>>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>>> the main thread in the debuggee could complete >>>>>>> before the dumpThreads enumeration is complete. >>>>>>> >>>>>>> DebuggerThreadTest >>>>>>> main() >>>>>>> startTests() >>>>>>> runTests() >>>>>>> startTo( "DebuggerThreadTarg.ready()") >>>>>>> dumpThreads() >>>>>>> listenUntilVMDisconnect() >>>>>>> >>>>>>> DebuggerThreadTarg >>>>>>> main() >>>>>>> ready() >>>>>>> >>>>>>> Revised fix: >>>>>>> - Prevents the NPE from a finished thread group >>>>>>> - Fails the test with a message indicating >>>>>>> number of premature completed threads. >>>>>>> >>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> /* >>>>>>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>> * >>>>>>> * This code is free software; you can redistribute it and/or >>>>>>> modify it >>>>>>> @@ -76,8 +76,16 @@ >>>>>>> Thread list[] = new Thread[listThreads * 2]; >>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>> for (int i = 0; i < Math.min(gotThreads, list.length); >>>>>>> i++){ >>>>>>> + int finishedThreads = 0; >>>>>>> Thread t = list[i]; >>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>> + String groupName; >>>>>>> + if (tga == null) { >>>>>>> + groupName = ""; >>>>>>> + finishedThreads++ ; >>>>>>> + } else { >>>>>>> + groupName =tga.getName(); >>>>>>> + } >>>>>>> >>>>>>> System.out.println("Thread [" + i + "] group = '" + >>>>>>> groupName + >>>>>>> @@ -89,7 +97,10 @@ >>>>>>> failure("FAIL: non-daemon thread '" + >>>>>>> t.getName() + >>>>>>> "' found in ThreadGroup '" + groupName >>>>>>> + "'"); >>>>>>> } >>>>>>> - >>>>>>> + if (finishedThreads > 0 ) { >>>>>>> + failure("FAIL: " + finishedThreads + >>>>>>> + " threads completed while VM suspended."); >>>>>>> + } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>> The failed case only had: >>>>>>>> >>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon = >>>>>>>> true >>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon = >>>>>>>> true >>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>>>> >>>>>>>> That would indicate that 'main' is likely the thread that >>>>>>>> exited. Seems odd. Isn't that the thread that the test is >>>>>>>> executing in? >>>>>>>> >>>>>>>> If you can't reproduce it, maybe it would be better to commit a >>>>>>>> diagnostic fix like the one I suggested and keep an eye on it. >>>>>>>> However, it only seems to have failed once due to this reason, >>>>>>>> so unless it is a new problem we may never see it again. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>>>>>> I haven't been able to reproduce the problem locally. >>>>>>>>> Trying larger test runs on mach5 now. >>>>>>>>> >>>>>>>>> Here's the output from a successful test run. >>>>>>>>> If any of the threads exited, they would have a null group name. >>>>>>>>> >>>>>>>>> Howdy! >>>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon >>>>>>>>> = true >>>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon >>>>>>>>> = true >>>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>>>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>>>>>>> Thread [6] group = 'AgentVMThreadGroup' name = 'AgentVMThread' >>>>>>>>> daemon = false >>>>>>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>>>>> daemon = false >>>>>>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output reader' >>>>>>>>> daemon = false >>>>>>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' >>>>>>>>> daemon = true >>>>>>>>> Thread [10] group = 'InnocuousThreadGroup' name = >>>>>>>>> 'Common-Cleaner' daemon = true >>>>>>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal >>>>>>>>> Event Handler' daemon = true >>>>>>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>>>>>> Interface' daemon = true >>>>>>>>> Goodbye from DebuggerThreadTarg! >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>>>>>> Can you reproduce the problem? If so, maybe to find out which >>>>>>>>>> thread is a problem you could check for null, print the >>>>>>>>>> thread info, and then fail the test. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>>>>>> This patch will let the test continue and at least >>>>>>>>>>> let the list of threads be processed. >>>>>>>>>>> >>>>>>>>>>> The test walks up the parents to the initial thread >>>>>>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>>>>>> There is an inherent race condition in enumerate() >>>>>>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>>>>>> >>>>>>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>>>>>> Hi Gary, >>>>>>>>>>>> >>>>>>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>>>>>> Here's a quick fix to avoid the NPE using a >>>>>>>>>>>>> getThreadGroup() which could be null >>>>>>>>>>>>> if the thread has terminated. >>>>>>>>>>>>> >>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>>>>>>>> for (int i = 0; i < Math.min(gotThreads, >>>>>>>>>>>>> list.length); i++){ >>>>>>>>>>>>> Thread t = list[i]; >>>>>>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>>>>>> tga.getName()); >>>>>>>>>>>>> >>>>>>>>>>>>> System.out.println("Thread [" + i + "] group >>>>>>>>>>>>> = '" + >>>>>>>>>>>>> groupName + >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > From gary.adams at oracle.com Wed Sep 12 15:43:21 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 12 Sep 2018 11:43:21 -0400 Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false In-Reply-To: <5B687D3D.8020908@oracle.com> References: <5B082D2E.7000408@oracle.com> <5d58fa2b-7dda-db64-0280-1e19e791a86d@oracle.com> <5B5233DC.5040003@oracle.com> <853aba55-fafc-2797-ed44-818760bd5571@oracle.com> <352ccc2d-8e8a-4b43-45fd-64bed2bb56f1@oracle.com> <973a96aa-0533-1e7d-a6f7-e948c0ecc371@oracle.com> <8a256bfc-1ff1-da31-ce31-75099f850461@oracle.com> <5B687D3D.8020908@oracle.com> Message-ID: <5B993419.7020109@oracle.com> Here's an updated webrev including Chris's proposal for early prompt print outs for commands that could be interrupted by event processing before command prompt delivery. Issue: https://bugs.openjdk.java.net/browse/JDK-8169718 Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.02/ Changes include - removing the yield in vmInterrupted, to allow the event thread output to be less interspersed - improved the command prompts for cont, step, stepi and next to be less likely to be interspersed with event output - avoid NPE in printCurrentLocation if current thread is invalidated On 8/6/18, 12:54 PM, Gary Adams wrote: > On 7/30/18, 12:46 PM, Chris Plummer wrote: >> On 7/30/18 12:47 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> Just one quick simple comment below. >>> >>> On 7/29/18 22:05, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> I updated my changes to do the wait() for step, stepi, cont, and >>>> next. Some issues turned up when testing. A number of tests were >>>> timing out occasionally, I believe because sometimes the event was >>>> handled (and the notify() call already completed) before we ever >>>> got to the handler.wait() call. >>> >>> I agree as I had this exact concern when was looking at the webrev.0. >>> Need more time to understand all the details. >> Hopefully it's a moot point since my 2nd version doesn't rely on any >> synchronization. >> >> http://cr.openjdk.java.net/~cjplummer/8169718/webrev.01/ >> >> I think a properly working synchronized version would require a large >> synchronized block in TTY::executeCommand() to block out any event >> handling until the prompt has been printed. I think this is safe even >> when you have a monitor command in place. Although that results in >> TTY::executeCommand() being called from the event handler, and it may >> temporarily block if the command thread is already in >> TTY::executeCommand(), eventually the command thread will exit the >> synchronized block allowing the event thread to make progress. Having >> said that, I just assume stick with the simpler webrev above if no >> one see issues with it. > > I like the approach used here - to print the prompt immediately > and skip the the prompt at the bottom of the command processing. > > The original error though was an interspersed prompt disrupting > the event handler output, which came from another event > being processed. e.g. > "Breakpoint hit:" > prompt from previous event > printCurrentLocation() > > Let me try a few test runs with your patch > along with a diagnostic in printPrompt() > so we can identify the printPrompt caller. > > new Exception().printStackTrace() > > ... >> >> thanks, >> >> Chris >>> >>> Thanks, >>> Serguei >>> >>> >>>> Although I never confirmed this was the cause, it certainly seems >>>> feasible. >>>> >>>> There were also issues with the prompt printed by >>>> TTY:executeCommand(). I've come to realize that it should really >>>> always be printed before any event handling. Currently that seems >>>> to be the case, probably due to the Thread.yield() I mention below >>>> in event handling code like stepEvent(), although I don't think >>>> it's necessarily guaranteed. However, with my changes prompt was >>>> always printed after the event was done being handled, and this >>>> proved to be a problem for some tests. >>>> >>>> When executing the "cont" command, it seems this prompt is expected >>>> to be "> ", which is the prompt printed if the VM is not currently >>>> suspended. Some tests count on this, mostly because they call >>>> jdb.receiveReplyFor(), and pass in the number of prompts that are >>>> expected. jdb.receiveReplyFor() does not count "> ". My change >>>> ended up making the printPrompt() in TTY:executeCommand() print as >>>> "main[1]" after a "cont" command, because the added synchronizing >>>> was making it not print until the thread was suspended. This caused >>>> some tests to fail because the expected reply was not yet received, >>>> even after jdb.receiveReplyFor() had returned (it was basically >>>> returning one prompt too soon). >>>> >>>> I started thinking that the synchronized approach probably needs a >>>> large synchronized block in TTY:executeCommand(). But then I >>>> figured out a much easier solution. Thinking more about the >>>> "prompt after cont" issue, it occurred to me that maybe we just >>>> need to print out the prompt before executing the command, so it's >>>> not possible for events to come in before the prompt is printed (or >>>> worse yet, in the middle of event handling output). Doing this ends >>>> up looking much like your original suggestion to set printPrompt = >>>> false for "cont", "step", "stepi", and "next", except I also added >>>> a call printPrompt() before doing this (Dan an I had rejected your >>>> proposal to simply remove the prompt, since it did server a >>>> purpose). For example: >>>> >>>> } else if (cmd.equals("cont")) { >>>> MessageOutput.printPrompt(); >>>> showPrompt = false; >>>> evaluator.commandCont(); >>>> >>>> But this does cause the issue I brought up above that the prompt >>>> from "cont" is expected (by a number of tests) to be "> ", but >>>> since the above code is executed while the vm is suspended, it ends >>>> up being main[1]. I fixed this by adding a "simple" argument to >>>> printPrompt() so we can force it to be "> " when needed. This will >>>> maintain compatibility with anyone making assumptions about what >>>> the prompt should look like. >>>> >>>> Here's the webrev, which seems to be working. I've run about 1000 >>>> iterations on all platforms. So far it seems to be working. There >>>> have been some failures, but for the most part I've also seen those >>>> with clean repos, and the ones that I haven't I don't believe are >>>> related to my changes. >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8169718/webrev.01/ >>>> >>>> One other comment about your initial fix to set showPrompt = false: >>>> >>>> + showPrompt = false; // asynchronous command >>>> >>>> I'm not sure if the "asynchronous command" comment was intentional >>>> or just the result of the copy-and-paste. I just want to clarify >>>> what is meant by "asynchronous command" in the other places where >>>> this comment appears. There are a few commands that are executed >>>> async on a different thread. If you look in Commands.java, you'll >>>> see how these commands use the AsyncExecution class to handle >>>> execution of the command. I'm not sure why this is done, because >>>> all these commands look like ones that are inherently synchronous, >>>> yet they are always run on a different thread, and as a result may >>>> not be complete when execution returns to TTY::executeCommand(). >>>> These commands also all set showPrompt = false, but the prompt is >>>> printed by AsyncExecution when complete. So, the point is the >>>> commands which are inherently async, like "step" and "cont", are >>>> not async w.r.t. these "asynchronous command" comments or the >>>> AsyncExecution class. >>>> >>>> Chris >>>> >>>> >>>> On 7/27/18 4:27 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> Sorry about the delay in the review. Been trying to fully >>>>> understand all the various code flows, which is tricky due to >>>>> having the separate event thread whose output needs to be >>>>> co-ordinated with command thread. Also made more complicated by >>>>> the multiple entrypoints into executeCommand(), and there being >>>>> various places where output produced and we care about the order. >>>>> I think I have it all mapped out now and a pretty good >>>>> understanding of how it all works. >>>>> >>>>> My first impression is that it seems like a large number of >>>>> changes and a lot of passing around of a StringBuffer object to >>>>> fix a problem which I think could be resolved with some strategic >>>>> wait/notify code. For example, it might be as simple as doing >>>>> something like this: >>>>> >>>>> http://cr.openjdk.java.net/~cjplummer/8169718/webrev.00/ >>>>> >>>>> This only covers the step command. You'd have to figure out which >>>>> other commands need to ensure an event has been processed before >>>>> printing the prompt, and set waitForEventCompletion = true for >>>>> them. Is there a reason not to go with something like this? >>>>> >>>>> As for you current changes, just a couple of things I've noticed, >>>>> but I have not given it a thorough review (for example, making >>>>> sure that the StringBuffer is always eventually printed, and done >>>>> so in the right order). >>>>> >>>>> In EventHandler.run(), it's unclear who is handling the printing >>>>> of sb when handleEvent() or handleDisconnectedException() are called. >>>>> >>>>> In the following EventHandler code: >>>>> >>>>> 123 @Override >>>>> 124 public void stepEvent(StepEvent se, StringBuilder sb) { >>>>> 125 Thread.yield(); // fetch output >>>>> 126 sb.append(MessageOutput.format("Step completed:")); >>>>> 127 } >>>>> >>>>> Do you understand why the Thread.yield() is there? What does the >>>>> comment mean by "fetch output"? Just seems like it has something >>>>> to do with the ordering of output, but it seems bad that the code >>>>> ever relied on a yield to make sure the output was ordered properly. >>>>> >>>>> Also in the above code snippet, you need to be careful when >>>>> replacing MessageOutput.lnprint() with MessageOutput.format(). >>>>> lnprint() adds a newline to the start of the line. That appears to >>>>> be missing in your code above. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 7/20/18 12:11 PM, Gary Adams wrote: >>>>>> Here's another attempt to clear up the overlapping output from >>>>>> the command processing and event handler in the jdb tests. >>>>>> >>>>>> The fundamental problem is observed when "prompts" >>>>>> are produced interleaved with command and event output. >>>>>> >>>>>> This attempts to fix the issue by buffering the output and >>>>>> printing it fully assembled. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.01/ >>>>>> >>>>>> On 5/26/18, 6:50 AM, gary.adams at oracle.com wrote: >>>>>>> This is a review request for a previously closed test bug. >>>>>>> The test was recently moved to the open repos, and the >>>>>>> proposed fix is in the open code. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev/ >>>>>>> >>>>>>> >>>>>>> -------- Forwarded Message -------- >>>>>>> Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: >>>>>>> Cannot find boolVar with expected value: false >>>>>>> Date: Fri, 25 May 2018 11:35:10 -0400 >>>>>>> From: Gary Adams >>>>>>> Reply-To: gary.adams at oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The jdb tests use stdin to send commands to a jdb process >>>>>>> and parses the stdout to determine if a command was >>>>>>> successful and when the process is prompting for new commands >>>>>>> to be sent. >>>>>>> >>>>>>> Some commands are synchronous, so when the command is completed >>>>>>> a new prompt is sent back immediately. >>>>>>> >>>>>>> Some commands are asynchronous, so there could be a delay >>>>>>> until a breakpoint is reached. The event handler then sends a prompt >>>>>>> when the application thread is stopped and new jdb commands can be sent. >>>>>>> >>>>>>> The problem causing the intermittent failures was a corruption in the >>>>>>> output stream when prompts were being sent at the wrong times. >>>>>>> >>>>>>> Instead of receiving >>>>>>> "Breakpoint hit:" >>>>>>> >>>>>>> >>>>>>> the log contained >>>>>>> "Breakpoint hit:" >>>>>>> >>>>>>> Once out of sync, jdb commands were being sent prematurely >>>>>>> and the wrong values were being compared against expected behavior. >>>>>>> The simple fix proposed here recognizes that commands like "cont", >>>>>>> "step" and "next" are asynchronous commands and should not send back >>>>>>> a prompt immediately. Instead. the event handler will deliver the next prompt >>>>>>> when the next "Breakpoint hit:" or "Step completed:" state change occurs. >>>>>>> >>>>>>> The bulk of the testing was done on windows-x64-debug builds where the >>>>>>> intermittent failures were observed in ~5 in 1000 testruns. The fix has >>>>>>> also been tested on linux-x64-debug, solaris-sparcv9-debug, >>>>>>> and macosx-x64-debug, even though the failures have never been reported >>>>>>> against those platforms. >>>>>>> >>>>>>> Failures have been observed in many of the nsk/jdb tests with similar corrupted >>>>>>> output streams, but never directly associated with this issue before. >>>>>>> >>>>>>> redefine001, caught_exception002, locals002, eval001, next001, >>>>>>> stop_at003, step002, print002, trace001, step_up001, read001, >>>>>>> clear004, kill001, set001 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 12 16:02:46 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 12 Sep 2018 09:02:46 -0700 Subject: RFR: 8209163: SA: Show Object Histogram asserts with ZGC In-Reply-To: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> References: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> Message-ID: Hi Per, I do not know this code but your need to call heapIterationFractionUpdate seems to be a code smell that something else could be fixed, no? Your webrev looks fine to me if I ignore the code smell that comes from having to call the update call: When I look at src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java, the reason it requires that first call is, like you said, that the frame is created only at the first heapIterationFractionUpdate. However, could we not test frame and if it is not created, don't try to remove it? Thanks, Jc On Wed, Sep 12, 2018 at 1:25 AM Per Liden wrote: > This patch avoids an assertion, and instead prints a warning, when > trying to show the "Object Histogram" when using ZGC. I also had to add > a call to heapIterationFractionUpdate() so that the update progress > frame is properly created, even when there are not heap regions to walk > over. Without this, you only get a call to heapIterationCompleted(), > with a null frame, which throws a NullPointerException. Always making a > call to heapIterationFractionUpdate(0.0) in the prologue avoids this by > making sure we always created the frame, even if no more fraction > updates will happen. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209163 > Webrev: http://cr.openjdk.java.net/~pliden/8209163/webrev.0 > > /Per > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 12 16:15:46 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 12 Sep 2018 09:15:46 -0700 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" In-Reply-To: <5B992262.5000509@oracle.com> References: <5B992262.5000509@oracle.com> Message-ID: Hi Gary, Just a remark that by replacing the first print command with a int x = 3; you are changing the test by adding a local. It does not matter because we are testing other variables, but we could add a line in the LOCALS table for x for completeness. Or we could just put an explicit return with the breakpoint comment, and the breakpoint will keep the tests consistent? (note: as a side story, this test is using explicit line numbers for the breakpoints but I've seen Alex add a lot of infrastructure to have an automatic parsing system to make it less error prone, we should update this test at some point). Just my 2 cents :-), Jc On Wed, Sep 12, 2018 at 7:27 AM Gary Adams wrote: > The print statements in the locals002 test have been observed to interfere > with the output from commands, replies and prompts used in the > synchronization > of operations between the debugger and debuggee. This change will remove > the > print statements. A follow up bug will be filed for longer term > investigation of the > character at a time output which leaves a larger window for the output > interruption > that occurs. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8208468 > > Proposed update: > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > @@ -81,7 +81,7 @@ > int[] arrVar > ) > { > - System.out.println("Arguments but no locals"); // > locals002.BREAKPOINT_LINE1 > + int x = 3; // locals002.BREAKPOINT_LINE1 > } > > static void allKindsOfLocals() { > @@ -97,6 +97,6 @@ > int[] arrVar = new int[5]; > > for (int j = 0; j < 5 ; j++) arrVar[j] = j; > - System.out.println("Locals but no arguments"); // > locals002.BREAKPOINT_LINE2 > + int x = 4; // locals002.BREAKPOINT_LINE2 > } > } > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Sep 12 18:12:41 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 12 Sep 2018 11:12:41 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests In-Reply-To: <798d3e43-261b-f4fb-9ede-cd0192bd2857@oracle.com> References: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> <798d3e43-261b-f4fb-9ede-cd0192bd2857@oracle.com> Message-ID: Hi Serguei, Updated webrev: http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.03/ --alex On 09/11/2018 22:15, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > It looks good. > > Just some minor comments. > > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/test/jdk/com/sun/jdi/lib/jdb/JdbTest.java.udiff.html > > + public LaunchOptions sourceFilename(String name) { > + sourceFilename = name; > + return this; > + } > > ? A suggestion is to rename this method to setSourceFilename. > > > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java.html > > 53 public ClassTransformer fileName(String fileName) { > 54 this.fileName = fileName; > 55 return this; > 56 } > > ? A suggestion is to rename this method to setFileName; > > ? It would be better for the comment at lines 107-135 to use the form: > ? /* > ?? *? ... > ?? */ > > Thanks, > Serguei > > > On 9/11/18 12:28, Alex Menkov wrote: >> Hi Jc, >> >> Thank you for review. >> Updated webrev (fixed both issue noted): >> http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/ >> >> --alex >> >> On 09/10/2018 21:00, JC Beyler wrote: >>> Hi Alex, >>> >>> I was looking at this and I have a few nits and questions: >>> - I saw two spots in the patch that had weird spaces: >>> test/jdk/com/sun/jdi/RedefineG.java >>> >>> +??????? super(? DEBUGGEE_CLASS, >>> +??????????????? "RedefineG.java"); >>> >>> - Then test/jdk/com/sun/jdi/RedefineImplementor.java >>> >>> +??????? super(? RedefineImplementorTarg.class.getName(), >>> +??????????????? "RedefineImplementor.java"); >>> >>> >>> - My only question is should we not be worried or care if both >>> test/jdk/com/sun/jdi/lib/jdb/JdbTest.java and >>> test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java have now ways that >>> could provoke NPEs? Should the code not try to throw an exception and >>> say: careful, you called this but didn't call that first? It would >>> make misuse of the class easier to debug when writing new tests. >>> >>> (Example being: calling redefineClass but not using the right >>> constructor) >>> >>> I know it is for testing only but if we start writing new tests, it >>> could be useful to be a bit defensive? >>> >>> >>> Apart from that, looked good to me. >>> >>> Jc >>> >>> >>> >>> On Mon, Sep 10, 2018 at 4:40 PM Alex Menkov >> > wrote: >>> >>> ??? Hi, >>> >>> ??? Please review a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8210560 >>> ??? webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.01/ >>> >>> >>> ??? New class (ClassTransformer) was developed to implement simple class >>> ??? transformer for class redefinition (the same functionality as >>> ??? implemented by ShellScaffold.sh). >>> >>> ??? Both setBreakpoint and redefineClass require source file name, so >>> ??? JdbTest class was updated to accept it as ctor argument and use by >>> ??? corresponding methods. >>> >>> ??? --alex >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc > From serguei.spitsyn at oracle.com Wed Sep 12 18:22:09 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Sep 2018 11:22:09 -0700 Subject: RFR: JDK-8210560: [TEST] convert com/sun/jdi redefineClass-related tests In-Reply-To: References: <045ebb65-db8e-0ef5-b432-a079dcf737a2@oracle.com> <798d3e43-261b-f4fb-9ede-cd0192bd2857@oracle.com> Message-ID: <07608e43-0c84-5140-1c01-e699ed647ecd@oracle.com> Hi Alex, Looks good. Thank you for the update! Thanks, Serguei On 9/12/18 11:12, Alex Menkov wrote: > Hi Serguei, > > Updated webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.03/ > > --alex > > On 09/11/2018 22:15, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> It looks good. >> >> Just some minor comments. >> >> http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/test/jdk/com/sun/jdi/lib/jdb/JdbTest.java.udiff.html >> >> >> + public LaunchOptions sourceFilename(String name) { >> + sourceFilename = name; >> + return this; >> + } >> >> ?? A suggestion is to rename this method to setSourceFilename. >> >> >> http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java.html >> >> >> ?? 53???? public ClassTransformer fileName(String fileName) { >> ?? 54???????? this.fileName = fileName; >> ?? 55???????? return this; >> ?? 56???? } >> >> ?? A suggestion is to rename this method to setFileName; >> >> ?? It would be better for the comment at lines 107-135 to use the form: >> ?? /* >> ??? *? ... >> ??? */ >> >> Thanks, >> Serguei >> >> >> On 9/11/18 12:28, Alex Menkov wrote: >>> Hi Jc, >>> >>> Thank you for review. >>> Updated webrev (fixed both issue noted): >>> http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.02/ >>> >>> --alex >>> >>> On 09/10/2018 21:00, JC Beyler wrote: >>>> Hi Alex, >>>> >>>> I was looking at this and I have a few nits and questions: >>>> - I saw two spots in the patch that had weird spaces: >>>> test/jdk/com/sun/jdi/RedefineG.java >>>> >>>> +??????? super(? DEBUGGEE_CLASS, >>>> +??????????????? "RedefineG.java"); >>>> >>>> - Then test/jdk/com/sun/jdi/RedefineImplementor.java >>>> >>>> +??????? super(? RedefineImplementorTarg.class.getName(), >>>> +??????????????? "RedefineImplementor.java"); >>>> >>>> >>>> - My only question is should we not be worried or care if both >>>> test/jdk/com/sun/jdi/lib/jdb/JdbTest.java and >>>> test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java have now ways >>>> that could provoke NPEs? Should the code not try to throw an >>>> exception and say: careful, you called this but didn't call that >>>> first? It would make misuse of the class easier to debug when >>>> writing new tests. >>>> >>>> (Example being: calling redefineClass but not using the right >>>> constructor) >>>> >>>> I know it is for testing only but if we start writing new tests, it >>>> could be useful to be a bit defensive? >>>> >>>> >>>> Apart from that, looked good to me. >>>> >>>> Jc >>>> >>>> >>>> >>>> On Mon, Sep 10, 2018 at 4:40 PM Alex Menkov >>>> > wrote: >>>> >>>> ??? Hi, >>>> >>>> ??? Please review a fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8210560 >>>> ??? webrev: >>>> http://cr.openjdk.java.net/~amenkov/sh2java/redefineClasses1/webrev.01/ >>>> >>>> >>>> >>>> >>>> ??? New class (ClassTransformer) was developed to implement simple >>>> class >>>> ??? transformer for class redefinition (the same functionality as >>>> ??? implemented by ShellScaffold.sh). >>>> >>>> ??? Both setBreakpoint and redefineClass require source file name, so >>>> ??? JdbTest class was updated to accept it as ctor argument and use by >>>> ??? corresponding methods. >>>> >>>> ??? --alex >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >> From jcbeyler at google.com Wed Sep 12 18:45:09 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 12 Sep 2018 11:45:09 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests Message-ID: Hi all, I am continuing the clean up of the testbase with the next batch, I know this is getting repetitive but bear with me please, after this webrev, we have in vmTestbase: - 29 more files that have the JNI_ENV* or JVMTI_ENV* macros (for a subsequent webrev) - 400+ files that have trivial #ifdef __cplusplus macros around the extern "C" and the final } (for a second subsequent webrev) After those two webrev, we can go to doing more important refactoring to get the vmTestbase in shape to start migrating out of there hopefully. So, without further ado, here is another one with 50 file changes and 1283 line changes. Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 This passes testing for the changed tests on my dev machine. Thanks for your reviews, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 12 19:10:13 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 12:10:13 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: Message-ID: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 12 19:35:05 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 12:35:05 -0700 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" In-Reply-To: <5B992262.5000509@oracle.com> References: <5B992262.5000509@oracle.com> Message-ID: Looks good. I filed JDK-8210668 to address to root issue. Chris On 9/12/18 7:27 AM, Gary Adams wrote: > The print statements in the locals002 test have been observed to > interfere > with the output from commands, replies and prompts used in the > synchronization > of operations between the debugger and debuggee. This change will > remove the > print statements. A follow up bug will be filed for longer term > investigation of the > character at a time output which leaves a larger window for the output > interruption > that occurs. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208468 > > Proposed update: > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java > @@ -81,7 +81,7 @@ > ??????? int[]?? arrVar > ?????????????????????????????? ) > ??? { > -?????? System.out.println("Arguments but no locals"); // > locals002.BREAKPOINT_LINE1 > +?????? int x = 3; // locals002.BREAKPOINT_LINE1 > ??? } > > ??? static void allKindsOfLocals()? { > @@ -97,6 +97,6 @@ > ??????? int[]?? arrVar??? = new int[5]; > > ??????? for (int j = 0; j < 5 ; j++) arrVar[j] = j; > -?????? System.out.println("Locals but no arguments"); // > locals002.BREAKPOINT_LINE2 > +?????? int x = 4; // locals002.BREAKPOINT_LINE2 > ??? } > ?} > From chris.plummer at oracle.com Wed Sep 12 19:38:14 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 12:38:14 -0700 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" In-Reply-To: References: <5B992262.5000509@oracle.com> Message-ID: <6a0fe21d-2604-32e6-e71f-b28c8b7eefb5@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 12 19:42:17 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 12:42:17 -0700 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <5B992ECF.4060000@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> <5B90251D.600@oracle.com> <91580473-07d0-84bf-18c5-3e92b38b00cd@oracle.com> <5B902B70.8080700@oracle.com> <5B992ECF.4060000@oracle.com> Message-ID: <69612781-6061-e2fe-9e30-dcd234e49e3d@oracle.com> Looks good. Chris On 9/12/18 8:20 AM, Gary Adams wrote: > Here's the updated webrev to avoid the NPE, but still > fail the test with more information about the premature > completed threads. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 > ? Webrev: http://cr.openjdk.java.net/~gadams/8210252/webrev.00/ > > On 9/5/18, 3:16 PM, Gary Adams wrote: >> After a quick local check of finishedThreads =1, >> I moved the check til after the full list of threads is checked, >> rather than repeating the stderr failure after each entry was >> processed. >> >> I also implemented a resumeVM() in TestScaffold and called it before >> dumpThreads(). That did not fail locally, so I submitted a mach5 job >> so I can >> run more tests in batches. >> >> ... >> >> On 9/5/18, 2:56 PM, Chris Plummer wrote: >>> I was thinking something like the resume() call. At the very least >>> just try setting finishedThreads = 1 to exercise the error handling. >>> >>> Chris >>> >>> ?On 9/5/18 11:49 AM, Gary Adams wrote: >>>> I had tried sleeping after each entry in dumpThreads was checked, >>>> but the >>>> failure never occurred. >>>> >>>> I had tried using mach5 --jvm-args to set UseZGC, but that never >>>> failed. >>>> >>>> Could attempt a resume() before calling dumpThreads() - haven't >>>> tried that , yet. >>>> >>>> On 9/5/18, 2:31 PM, Chris Plummer wrote: >>>>> Ok. Have you found a way to test your changes? Maybe just force or >>>>> simulate a failure somehow. >>>>> >>>>> Chris >>>>> >>>>> On 9/5/18 11:26 AM, Gary Adams wrote: >>>>>> If we go ahead with this proposed fix, the next time it fails >>>>>> we will have more information about the other threads >>>>>> captured in the log. >>>>>> >>>>>> One last observation, the test that failed was running with UseZGC. >>>>>> Not sure how that might impact this particular test. >>>>>> >>>>>> On 9/5/18, 2:07 PM, Chris Plummer wrote: >>>>>>> >>>>>>> Hi Gary, >>>>>>> >>>>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>>> >>>>>>> The failure explanation seems to hinge on this, but I don't see >>>>>>> how this can happen. What is resuming DebugThreadTarg? Only the >>>>>>> call to listenUntilVMDisconnect() should be doing this, and we >>>>>>> aren't even getting that far. The only thing I can think of is >>>>>>> due to some other issue (maybe host out of memory so process was >>>>>>> killed off), the DebugThreadTarg process has exited >>>>>>> unexpectedly. In this case I guess the fix you have is >>>>>>> appropriate defensive programming, causing the test to fail when >>>>>>> this happens, but still won't explain why it happens and also >>>>>>> won't prevent future failures of this test. Also, this type of >>>>>>> Debuggee early exit problem could happen with other tests too. >>>>>>> I'm leaning towards just closing this bug as CNR. I don't think >>>>>>> we want to be writing our tests to defend against random system >>>>>>> related failures, especially when the end result is still going >>>>>>> to be a test failure that we don't fully understand. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/5/18 7:33 AM, Gary Adams wrote: >>>>>>>> The DebuggerThreadTest ensures it is in sync >>>>>>>> at the beginning of RunTests with a breakpoint event >>>>>>>> in DebuggerThreadTarg ready() method. >>>>>>>> >>>>>>>> The DebuggerThreadTest then continues with >>>>>>>> dumpThreads() and listenUntilVMDisconnect() >>>>>>>> completes. >>>>>>>> >>>>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>>>> the main thread in the debuggee could complete >>>>>>>> before the dumpThreads enumeration is complete. >>>>>>>> >>>>>>>> DebuggerThreadTest >>>>>>>> ? main() >>>>>>>> ??? startTests() >>>>>>>> ?????? runTests() >>>>>>>> ????????? startTo( "DebuggerThreadTarg.ready()") >>>>>>>> ????????? dumpThreads() >>>>>>>> ????????? listenUntilVMDisconnect() >>>>>>>> >>>>>>>> DebuggerThreadTarg >>>>>>>> ? main() >>>>>>>> ???? ready() >>>>>>>> >>>>>>>> Revised fix: >>>>>>>> ? - Prevents the NPE from a finished thread group >>>>>>>> ? - Fails the test with a message indicating >>>>>>>> ???? number of premature completed threads. >>>>>>>> >>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>> ?/* >>>>>>>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All >>>>>>>> rights reserved. >>>>>>>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>>>>>> rights reserved. >>>>>>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>> ? * >>>>>>>> ? * This code is free software; you can redistribute it and/or >>>>>>>> modify it >>>>>>>> @@ -76,8 +76,16 @@ >>>>>>>> ???????? Thread list[] = new Thread[listThreads * 2]; >>>>>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>>>>> ???????? for (int i = 0; i < Math.min(gotThreads, list.length); >>>>>>>> i++){ >>>>>>>> +??????????? int finishedThreads = 0; >>>>>>>> ???????????? Thread t = list[i]; >>>>>>>> -??????????? String groupName = t.getThreadGroup().getName(); >>>>>>>> +??????????? ThreadGroup tga = t.getThreadGroup(); >>>>>>>> +??????????? String groupName; >>>>>>>> +??????????? if (tga == null) { >>>>>>>> +??????????????? groupName = ""; >>>>>>>> +??????????????? finishedThreads++ ; >>>>>>>> +??????????? } else { >>>>>>>> +??????????????? groupName =tga.getName(); >>>>>>>> +??????????? } >>>>>>>> >>>>>>>> ???????????? System.out.println("Thread [" + i + "] group = '" + >>>>>>>> ??????????????????????????????? groupName + >>>>>>>> @@ -89,7 +97,10 @@ >>>>>>>> ???????????????? failure("FAIL: non-daemon thread '" + >>>>>>>> t.getName() + >>>>>>>> ???????????????????????? "' found in ThreadGroup '" + groupName >>>>>>>> + "'"); >>>>>>>> ???????????? } >>>>>>>> - >>>>>>>> +??????????? if (finishedThreads > 0 ) { >>>>>>>> +??????????????? failure("FAIL: " + finishedThreads + >>>>>>>> +??????????????????????? " threads completed while VM >>>>>>>> suspended."); >>>>>>>> +??????????? } >>>>>>>> ???????? } >>>>>>>> ???? } >>>>>>>> >>>>>>>> >>>>>>>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> The failed case only had: >>>>>>>>> >>>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon >>>>>>>>> = true >>>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon >>>>>>>>> = true >>>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = true >>>>>>>>> >>>>>>>>> That would indicate that 'main' is likely the thread that >>>>>>>>> exited. Seems odd. Isn't that the thread that the test is >>>>>>>>> executing in? >>>>>>>>> >>>>>>>>> If you can't reproduce it, maybe it would be better to commit >>>>>>>>> a diagnostic fix like the one I suggested and keep an eye on >>>>>>>>> it. However, it only seems to have failed once due to this >>>>>>>>> reason, so unless it is a new problem we may never see it again. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>>>>>>> I haven't been able to reproduce the problem locally. >>>>>>>>>> Trying larger test runs on mach5 now. >>>>>>>>>> >>>>>>>>>> Here's the output from a successful test run. >>>>>>>>>> If any of the threads exited, they would have a null group name. >>>>>>>>>> >>>>>>>>>> Howdy! >>>>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon >>>>>>>>>> = true >>>>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon >>>>>>>>>> = true >>>>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = >>>>>>>>>> true >>>>>>>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>>>>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = true >>>>>>>>>> Thread [6] group = 'AgentVMThreadGroup' name = >>>>>>>>>> 'AgentVMThread' daemon = false >>>>>>>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output >>>>>>>>>> reader' daemon = false >>>>>>>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output >>>>>>>>>> reader' daemon = false >>>>>>>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' >>>>>>>>>> daemon = true >>>>>>>>>> Thread [10] group = 'InnocuousThreadGroup' name = >>>>>>>>>> 'Common-Cleaner' daemon = true >>>>>>>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal >>>>>>>>>> Event Handler' daemon = true >>>>>>>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>>>>>>> Interface' daemon = true >>>>>>>>>> Goodbye from DebuggerThreadTarg! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>>>>>>> Can you reproduce the problem? If so, maybe to find out >>>>>>>>>>> which thread is a problem you could check for null, print >>>>>>>>>>> the thread info, and then fail the test. >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>>>>>>> This patch will let? the test continue and at least >>>>>>>>>>>> let the list of threads be processed. >>>>>>>>>>>> >>>>>>>>>>>> The test walks up the parents to the initial thread >>>>>>>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>>>>>>> There is an inherent race condition in enumerate() >>>>>>>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>>>>>>> >>>>>>>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>>>>>>> Hi Gary, >>>>>>>>>>>>> >>>>>>>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>>>>>>> >>>>>>>>>>>>> Chris >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>>>>>>> Here's a quick fix to avoid the NPE using a >>>>>>>>>>>>>> getThreadGroup() which could be null >>>>>>>>>>>>>> if the thread has terminated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>>>>>>> ???????? int gotThreads = tg.enumerate(list, true); >>>>>>>>>>>>>> ???????? for (int i = 0; i < Math.min(gotThreads, >>>>>>>>>>>>>> list.length); i++){ >>>>>>>>>>>>>> ???????????? Thread t = list[i]; >>>>>>>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>>>>>>> tga.getName()); >>>>>>>>>>>>>> >>>>>>>>>>>>>> ???????????? System.out.println("Thread [" + i + "] group >>>>>>>>>>>>>> = '" + >>>>>>>>>>>>>> groupName + >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From chris.plummer at oracle.com Wed Sep 12 19:46:06 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 12:46:06 -0700 Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false In-Reply-To: <5B993419.7020109@oracle.com> References: <5B082D2E.7000408@oracle.com> <5d58fa2b-7dda-db64-0280-1e19e791a86d@oracle.com> <5B5233DC.5040003@oracle.com> <853aba55-fafc-2797-ed44-818760bd5571@oracle.com> <352ccc2d-8e8a-4b43-45fd-64bed2bb56f1@oracle.com> <973a96aa-0533-1e7d-a6f7-e948c0ecc371@oracle.com> <8a256bfc-1ff1-da31-ce31-75099f850461@oracle.com> <5B687D3D.8020908@oracle.com> <5B993419.7020109@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Sep 12 20:51:47 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 12 Sep 2018 13:51:47 -0700 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" In-Reply-To: References: <5B992262.5000509@oracle.com> Message-ID: <0ede46ea-b952-352e-5c7d-6d91f45d47e1@oracle.com> +1 for the fix as a temporary workaround. Actually that's look a bit strange as debuggee output is redirected. So I'd expected it does not go through jdb log, and it should appear in the test log with "debuggee.stdout>" prefix. -alex On 09/12/2018 12:35, Chris Plummer wrote: > Looks good. I filed JDK-8210668 to address to root issue. > > Chris > > On 9/12/18 7:27 AM, Gary Adams wrote: >> The print statements in the locals002 test have been observed to >> interfere >> with the output from commands, replies and prompts used in the >> synchronization >> of operations between the debugger and debuggee. This change will >> remove the >> print statements. A follow up bug will be filed for longer term >> investigation of the >> character at a time output which leaves a larger window for the output >> interruption >> that occurs. >> >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208468 >> >> Proposed update: >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> @@ -81,7 +81,7 @@ >> ??????? int[]?? arrVar >> ?????????????????????????????? ) >> ??? { >> -?????? System.out.println("Arguments but no locals"); // >> locals002.BREAKPOINT_LINE1 >> +?????? int x = 3; // locals002.BREAKPOINT_LINE1 >> ??? } >> >> ??? static void allKindsOfLocals()? { >> @@ -97,6 +97,6 @@ >> ??????? int[]?? arrVar??? = new int[5]; >> >> ??????? for (int j = 0; j < 5 ; j++) arrVar[j] = j; >> -?????? System.out.println("Locals but no arguments"); // >> locals002.BREAKPOINT_LINE2 >> +?????? int x = 4; // locals002.BREAKPOINT_LINE2 >> ??? } >> ?} >> > From jcbeyler at google.com Wed Sep 12 20:54:37 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 12 Sep 2018 13:54:37 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> Message-ID: Hi Chris, Thanks for the review! That remark is exactly what I was thinking for a lot of these files but then this process would go even slower. A lot of the coding style in these tests seem out of sync with the rest of hotspot and what I would normally expect to see. I have forced myself not to touch them yet and, right now, I was working at this in doing similar changes across the board but keeping it simple to review. I (for fun?) went through ji05t001.cpp and looked quickly what I would change (regardless of coding guidelines). Note the quickly, I really only looked at general formatting and what we could/should perhaps do automatically across the others files at some point. I basically noted: - no {} around the body of an if, regardless if it is a one-liner afterwards - missing spaces before/after ==, !=, (etc), ?, : - assignments in an if - potentially putting back on one line when it seems still readable Would you have a second to look at the incremental change: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp.udiff.html I'm suggesting however, for this change, to do this: - only apply your remark on the make the 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env ...\n", (indx==0)?"A":"B"); into two lines. And not do the other changes in this incremental to keep vmTestbase relatively consistent across the board for now. Then, when you (and others) tell me what you think are the important items of the list above and what changes were done in the incremental that you think are not useful, I'll file a bug and, when done with other refactoring, start hitting those (we will just need to find reviewers who are willing to go through the more intense/involved webrevs). What do you think and thanks for your all reviews! Jc On Wed, Sep 12, 2018 at 12:10 PM Chris Plummer wrote: > Hi JC, > > Just a couple of minor suggestions in ji05t001.cpp: > > 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env > ...\n", (indx==0)?"A":"B"); > > I think I like this better as two lines. > > 204 if ((err = jvmti[indx]->SetEventNotificationMode(JVMTI_ENABLE, > 205 JVMTI_EVENT_VM_INIT, NULL)) != JVMTI_ERROR_NONE) { /* > enable event globally */ > > If I had my way you'd be making a couple dozen changes to remove > assignments from conditional expressions, but I've been shot down when > suggesting this in the past because doing this is considered within the > coding guidelines. However, when the conditional takes up two lines, it > really does start to become too hard to read. I'd suggest assigning "err" > before the "if". > > thanks, > > Chris > > On 9/12/18 11:45 AM, JC Beyler wrote: > > Hi all, > > I am continuing the clean up of the testbase with the next batch, I know > this is getting repetitive but bear with me please, after this webrev, we > have in vmTestbase: > > - 29 more files that have the JNI_ENV* or JVMTI_ENV* macros (for a > subsequent webrev) > - 400+ files that have trivial #ifdef __cplusplus macros around the extern > "C" and the final } (for a second subsequent webrev) > > After those two webrev, we can go to doing more important refactoring to > get the vmTestbase in shape to start migrating out of there hopefully. > > So, without further ado, here is another one with 50 file changes and 1283 > line changes. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 > > This passes testing for the changed tests on my dev machine. > > Thanks for your reviews, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 12 21:09:48 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 14:09:48 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 12 23:30:12 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 12 Sep 2018 16:30:12 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> Message-ID: Yes agreed, I actually have the same preferences for indentation and agreed for the multi-line string literals. And for changing the ifs. I actually created: - Assignments in ifs: https://bugs.openjdk.java.net/browse/JDK-8210687 -> I've hand-waved the number with a series of greps to about 600 cases in vmTestbase, so except if someone has strong beliefs that they should not get cleaned up, we should be able to do in one-two webrevs -> For reference I hand-waved to 3k in src/hotspot - Multi-line string litterals: https://bugs.openjdk.java.net/browse/JDK-8210689 -> I've hand-waved the number to being 77 cases in vmTestbase, so that is do-able in one webrev -> For reference I count 6ish cases in src/hotspot Does anyone see any issues trying to handle these after the macro cleanup? For this webrev, I then offer this one, what do you think Chris? Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.02/ Incremental: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 Thanks all! Jc On Wed, Sep 12, 2018 at 2:09 PM Chris Plummer wrote: > Hi JC, > > Overall I think your proposed ji05t001.cpp changes are a good idea, but I > would say "assignments in an if" is the one I care about the most (but > others seem to disagree on this). If you think you will get around to > fixing "assignments in an if" soon, then I'm fine leaving out my suggestion > for cleaning up the one multi-line case. Otherwise I'd like to see it fixed > with this CR. > > Here's another issue you missed that I've fixed in the past: > > 118 NSK_DISPLAY1("%s JVMTI env: doRedirect: the JNI function table > obtained successfully\n\ > 119 \toverwriting the function GetVersion() ...\n", > > Maybe it was written before C supported concatenation of string literals. > > Also you need some consistency with the following: > > 175 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env > ...\n", > 176 (indx == 0) ? "A" : "B"); > > 185 NSK_DISPLAY1("\nagent %s initializer: the JVMTI env > obtained\n\tsetting event callbacks ...\n", > 186 (indx == 0)? "A": "B"); > > I prefer the first version, indenting the arguments on the second line to > lineup with the first argument on the first line. I only do the latter if I > don't include any argument on the first line, which some times makes sense > if the method name is long, and possibly also is invoked using an object > with a long name (or is the result of a method call itself). > > thanks, > > Chris > > On 9/12/18 1:54 PM, JC Beyler wrote: > > Hi Chris, > > Thanks for the review! That remark is exactly what I was thinking for a > lot of these files but then this process would go even slower. A lot of the > coding style in these tests seem out of sync with the rest of hotspot and > what I would normally expect to see. I have forced myself not to touch them > yet and, right now, I was working at this in doing similar changes across > the board but keeping it simple to review. > > I (for fun?) went through ji05t001.cpp and looked quickly what I would > change (regardless of coding guidelines). Note the quickly, I really only > looked at general formatting and what we could/should perhaps do > automatically across the others files at some point. > > I basically noted: > - no {} around the body of an if, regardless if it is a one-liner > afterwards > - missing spaces before/after ==, !=, (etc), ?, : > - assignments in an if > - potentially putting back on one line when it seems still readable > > Would you have a second to look at the incremental change: > > http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp.udiff.html > > I'm suggesting however, for this change, to do this: > - only apply your remark on the make the > > 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env > ...\n", (indx==0)?"A":"B"); > > into two lines. > > And not do the other changes in this incremental to keep vmTestbase > relatively consistent across the board for now. > > Then, when you (and others) tell me what you think are the important items > of the list above and what changes were done in the incremental that you > think are not useful, I'll file a bug and, when done with other > refactoring, start hitting those (we will just need to find reviewers who > are willing to go through the more intense/involved webrevs). > > What do you think and thanks for your all reviews! > Jc > > On Wed, Sep 12, 2018 at 12:10 PM Chris Plummer > wrote: > >> Hi JC, >> >> Just a couple of minor suggestions in ji05t001.cpp: >> >> 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >> ...\n", (indx==0)?"A":"B"); >> >> I think I like this better as two lines. >> >> 204 if ((err = jvmti[indx]->SetEventNotificationMode(JVMTI_ENABLE, >> 205 JVMTI_EVENT_VM_INIT, NULL)) != JVMTI_ERROR_NONE) { /* >> enable event globally */ >> >> If I had my way you'd be making a couple dozen changes to remove >> assignments from conditional expressions, but I've been shot down when >> suggesting this in the past because doing this is considered within the >> coding guidelines. However, when the conditional takes up two lines, it >> really does start to become too hard to read. I'd suggest assigning "err" >> before the "if". >> >> thanks, >> >> Chris >> >> On 9/12/18 11:45 AM, JC Beyler wrote: >> >> Hi all, >> >> I am continuing the clean up of the testbase with the next batch, I know >> this is getting repetitive but bear with me please, after this webrev, we >> have in vmTestbase: >> >> - 29 more files that have the JNI_ENV* or JVMTI_ENV* macros (for a >> subsequent webrev) >> - 400+ files that have trivial #ifdef __cplusplus macros around the >> extern "C" and the final } (for a second subsequent webrev) >> >> After those two webrev, we can go to doing more important refactoring to >> get the vmTestbase in shape to start migrating out of there hopefully. >> >> So, without further ado, here is another one with 50 file changes and >> 1283 line changes. >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 >> >> This passes testing for the changed tests on my dev machine. >> >> Thanks for your reviews, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Sep 12 23:43:27 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Sep 2018 16:43:27 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: Message-ID: <227f93c5-de98-fd3c-e998-9c90129397c6@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 13 00:28:54 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 17:28:54 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> Message-ID: <2febf117-49a2-a09a-c5d9-a4bb56f111e8@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 13 01:28:10 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 12 Sep 2018 18:28:10 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: <2febf117-49a2-a09a-c5d9-a4bb56f111e8@oracle.com> References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> <2febf117-49a2-a09a-c5d9-a4bb56f111e8@oracle.com> Message-ID: I was going to make the changes of the incremental in the same change. Then I'll work on the other fixes we talked about in subsequent webrevs when I'm done with the macro refactoring. ie: this is my fix for the file we were talking about: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp.udiff.html Let me know if that works for you, Jc On Wed, Sep 12, 2018 at 5:28 PM Chris Plummer wrote: > It looks fine, but are you going to make the incremental changes part of > 8210665, or file a different CR for them and fix all the files under it? > > thanks, > > Chris > > On 9/12/18 4:30 PM, JC Beyler wrote: > > Yes agreed, I actually have the same preferences for indentation and > agreed for the multi-line string literals. And for changing the ifs. I > actually created: > > - Assignments in ifs: https://bugs.openjdk.java.net/browse/JDK-8210687 > -> I've hand-waved the number with a series of greps to about 600 > cases in vmTestbase, so except if someone has strong beliefs that they > should not get cleaned up, we should be able to do in one-two webrevs > -> For reference I hand-waved to 3k in src/hotspot > > - Multi-line string litterals: > https://bugs.openjdk.java.net/browse/JDK-8210689 > -> I've hand-waved the number to being 77 cases in vmTestbase, so that > is do-able in one webrev > -> For reference I count 6ish cases in src/hotspot > > Does anyone see any issues trying to handle these after the macro cleanup? > > For this webrev, I then offer this one, what do you think Chris? > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.02/ > Incremental: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 > > Thanks all! > Jc > > > On Wed, Sep 12, 2018 at 2:09 PM Chris Plummer > wrote: > >> Hi JC, >> >> Overall I think your proposed ji05t001.cpp changes are a good idea, but >> I would say "assignments in an if" is the one I care about the most (but >> others seem to disagree on this). If you think you will get around to >> fixing "assignments in an if" soon, then I'm fine leaving out my suggestion >> for cleaning up the one multi-line case. Otherwise I'd like to see it fixed >> with this CR. >> >> Here's another issue you missed that I've fixed in the past: >> >> 118 NSK_DISPLAY1("%s JVMTI env: doRedirect: the JNI function table >> obtained successfully\n\ >> 119 \toverwriting the function GetVersion() ...\n", >> >> Maybe it was written before C supported concatenation of string literals. >> >> Also you need some consistency with the following: >> >> 175 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >> ...\n", >> 176 (indx == 0) ? "A" : "B"); >> >> 185 NSK_DISPLAY1("\nagent %s initializer: the JVMTI env >> obtained\n\tsetting event callbacks ...\n", >> 186 (indx == 0)? "A": "B"); >> >> I prefer the first version, indenting the arguments on the second line to >> lineup with the first argument on the first line. I only do the latter if I >> don't include any argument on the first line, which some times makes sense >> if the method name is long, and possibly also is invoked using an object >> with a long name (or is the result of a method call itself). >> >> thanks, >> >> Chris >> >> On 9/12/18 1:54 PM, JC Beyler wrote: >> >> Hi Chris, >> >> Thanks for the review! That remark is exactly what I was thinking for a >> lot of these files but then this process would go even slower. A lot of the >> coding style in these tests seem out of sync with the rest of hotspot and >> what I would normally expect to see. I have forced myself not to touch them >> yet and, right now, I was working at this in doing similar changes across >> the board but keeping it simple to review. >> >> I (for fun?) went through ji05t001.cpp and looked quickly what I would >> change (regardless of coding guidelines). Note the quickly, I really only >> looked at general formatting and what we could/should perhaps do >> automatically across the others files at some point. >> >> I basically noted: >> - no {} around the body of an if, regardless if it is a one-liner >> afterwards >> - missing spaces before/after ==, !=, (etc), ?, : >> - assignments in an if >> - potentially putting back on one line when it seems still readable >> >> Would you have a second to look at the incremental change: >> >> http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp.udiff.html >> >> I'm suggesting however, for this change, to do this: >> - only apply your remark on the make the >> >> 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >> ...\n", (indx==0)?"A":"B"); >> >> into two lines. >> >> And not do the other changes in this incremental to keep vmTestbase >> relatively consistent across the board for now. >> >> Then, when you (and others) tell me what you think are the important >> items of the list above and what changes were done in the incremental that >> you think are not useful, I'll file a bug and, when done with other >> refactoring, start hitting those (we will just need to find reviewers who >> are willing to go through the more intense/involved webrevs). >> >> What do you think and thanks for your all reviews! >> Jc >> >> On Wed, Sep 12, 2018 at 12:10 PM Chris Plummer >> wrote: >> >>> Hi JC, >>> >>> Just a couple of minor suggestions in ji05t001.cpp: >>> >>> 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >>> ...\n", (indx==0)?"A":"B"); >>> >>> I think I like this better as two lines. >>> >>> 204 if ((err = jvmti[indx]->SetEventNotificationMode(JVMTI_ENABLE, >>> 205 JVMTI_EVENT_VM_INIT, NULL)) != JVMTI_ERROR_NONE) { /* >>> enable event globally */ >>> >>> If I had my way you'd be making a couple dozen changes to remove >>> assignments from conditional expressions, but I've been shot down when >>> suggesting this in the past because doing this is considered within the >>> coding guidelines. However, when the conditional takes up two lines, it >>> really does start to become too hard to read. I'd suggest assigning "err" >>> before the "if". >>> >>> thanks, >>> >>> Chris >>> >>> On 9/12/18 11:45 AM, JC Beyler wrote: >>> >>> Hi all, >>> >>> I am continuing the clean up of the testbase with the next batch, I know >>> this is getting repetitive but bear with me please, after this webrev, we >>> have in vmTestbase: >>> >>> - 29 more files that have the JNI_ENV* or JVMTI_ENV* macros (for a >>> subsequent webrev) >>> - 400+ files that have trivial #ifdef __cplusplus macros around the >>> extern "C" and the final } (for a second subsequent webrev) >>> >>> After those two webrev, we can go to doing more important refactoring to >>> get the vmTestbase in shape to start migrating out of there hopefully. >>> >>> So, without further ado, here is another one with 50 file changes and >>> 1283 line changes. >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 >>> >>> This passes testing for the changed tests on my dev machine. >>> >>> Thanks for your reviews, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 13 03:01:44 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Sep 2018 20:01:44 -0700 Subject: RFR (M) 8210593: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[N-R] tests In-Reply-To: References: Message-ID: <7a570e4b-fa54-5471-3401-42956d762840@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 13 03:13:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Sep 2018 20:13:52 -0700 Subject: RFR (XL) 8210385: Clean up JNI_ENV_ARG and factorize the macros for remaining vmTestbase/jvmti tests In-Reply-To: References: <07f97508-1c92-e965-0b9e-3a58fd7ce7be@oracle.com> Message-ID: <443b022e-65b6-97d7-248f-5f7bd01b75e7@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 13 06:15:55 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 12 Sep 2018 23:15:55 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> <2febf117-49a2-a09a-c5d9-a4bb56f111e8@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From per.liden at oracle.com Thu Sep 13 10:48:03 2018 From: per.liden at oracle.com (Per Liden) Date: Thu, 13 Sep 2018 12:48:03 +0200 Subject: RFR: 8209163: SA: Show Object Histogram asserts with ZGC In-Reply-To: References: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> Message-ID: <0a9bbe3f-63f2-9014-d279-a57312e18f31@oracle.com> Hi JC, Thanks for reviewing. On 09/12/2018 06:02 PM, JC Beyler wrote: > Hi Per, > > I do not know this code but your need to > call?heapIterationFractionUpdate seems to be a code smell that something > else could be fixed, no? > > Your webrev looks fine to me if I ignore the code smell that comes from > having to call the update call: > > When I look at > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java, the > reason it requires that first call is, like you said, that the frame is > created only at the first heapIterationFractionUpdate. However, could we > not test frame and if it is not created, don't try to remove it? I actually did that initially, but had the feeling people would think that was an even worse code smell ;) I don't have a strong opinion on this, so I updated the webrev to check for null instead. http://cr.openjdk.java.net/~pliden/8209163/webrev.1 cheers, Per > > Thanks, > Jc > > On Wed, Sep 12, 2018 at 1:25 AM Per Liden > wrote: > > This patch avoids an assertion, and instead prints a warning, when > trying to show the "Object Histogram" when using ZGC. I also had to add > a call to heapIterationFractionUpdate() so that the update progress > frame is properly created, even when there are not heap regions to walk > over. Without this, you only get a call to heapIterationCompleted(), > with a null frame, which throws a NullPointerException. Always making a > call to heapIterationFractionUpdate(0.0) in the prologue avoids this by > making sure we always created the frame, even if no more fraction > updates will happen. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209163 > Webrev: http://cr.openjdk.java.net/~pliden/8209163/webrev.0 > > /Per > > > > -- > > Thanks, > Jc From gary.adams at oracle.com Thu Sep 13 11:51:58 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 13 Sep 2018 07:51:58 -0400 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" In-Reply-To: References: <5B992262.5000509@oracle.com> Message-ID: <5B9A4F5E.6090902@oracle.com> Patch attached. On 9/12/18, 3:35 PM, Chris Plummer wrote: > Looks good. I filed JDK-8210668 to address to root issue. > > Chris > > On 9/12/18 7:27 AM, Gary Adams wrote: >> The print statements in the locals002 test have been observed to >> interfere >> with the output from commands, replies and prompts used in the >> synchronization >> of operations between the debugger and debuggee. This change will >> remove the >> print statements. A follow up bug will be filed for longer term >> investigation of the >> character at a time output which leaves a larger window for the >> output interruption >> that occurs. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8208468 >> >> Proposed update: >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >> @@ -81,7 +81,7 @@ >> int[] arrVar >> ) >> { >> - System.out.println("Arguments but no locals"); // >> locals002.BREAKPOINT_LINE1 >> + int x = 3; // locals002.BREAKPOINT_LINE1 >> } >> >> static void allKindsOfLocals() { >> @@ -97,6 +97,6 @@ >> int[] arrVar = new int[5]; >> >> for (int j = 0; j < 5 ; j++) arrVar[j] = j; >> - System.out.println("Locals but no arguments"); // >> locals002.BREAKPOINT_LINE2 >> + int x = 4; // locals002.BREAKPOINT_LINE2 >> } >> } >> > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8208468.patch URL: From gary.adams at oracle.com Thu Sep 13 11:57:24 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 13 Sep 2018 07:57:24 -0400 Subject: RFR: JDK-8210252: com/sun/jdi/DebuggerThreadTest.java fails with NPE In-Reply-To: <69612781-6061-e2fe-9e30-dcd234e49e3d@oracle.com> References: <5B8E78F1.3080205@oracle.com> <5B8ECB7E.1000901@oracle.com> <4a4e9ada-2a8c-7257-7b93-3d01c6af9bc2@oracle.com> <5B8ECEDE.2040708@oracle.com> <5B8FE929.9060203@oracle.com> <5B901FC3.6080904@oracle.com> <69278251-0d81-e134-6b33-b243ce3f3881@oracle.com> <5B90251D.600@oracle.com> <91580473-07d0-84bf-18c5-3e92b38b00cd@oracle.com> <5B902B70.8080700@oracle.com> <5B992ECF.4060000@oracle.com> <69612781-6061-e2fe-9e30-dcd234e49e3d@oracle.com> Message-ID: <5B9A50A4.6010904@oracle.com> Patch attached. On 9/12/18, 3:42 PM, Chris Plummer wrote: > Looks good. > > Chris > > On 9/12/18 8:20 AM, Gary Adams wrote: >> Here's the updated webrev to avoid the NPE, but still >> fail the test with more information about the premature >> completed threads. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >> Webrev: http://cr.openjdk.java.net/~gadams/8210252/webrev.00/ >> >> On 9/5/18, 3:16 PM, Gary Adams wrote: >>> After a quick local check of finishedThreads =1, >>> I moved the check til after the full list of threads is checked, >>> rather than repeating the stderr failure after each entry was >>> processed. >>> >>> I also implemented a resumeVM() in TestScaffold and called it before >>> dumpThreads(). That did not fail locally, so I submitted a mach5 job >>> so I can >>> run more tests in batches. >>> >>> ... >>> >>> On 9/5/18, 2:56 PM, Chris Plummer wrote: >>>> I was thinking something like the resume() call. At the very least >>>> just try setting finishedThreads = 1 to exercise the error handling. >>>> >>>> Chris >>>> >>>> On 9/5/18 11:49 AM, Gary Adams wrote: >>>>> I had tried sleeping after each entry in dumpThreads was checked, >>>>> but the >>>>> failure never occurred. >>>>> >>>>> I had tried using mach5 --jvm-args to set UseZGC, but that never >>>>> failed. >>>>> >>>>> Could attempt a resume() before calling dumpThreads() - haven't >>>>> tried that , yet. >>>>> >>>>> On 9/5/18, 2:31 PM, Chris Plummer wrote: >>>>>> Ok. Have you found a way to test your changes? Maybe just force >>>>>> or simulate a failure somehow. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/5/18 11:26 AM, Gary Adams wrote: >>>>>>> If we go ahead with this proposed fix, the next time it fails >>>>>>> we will have more information about the other threads >>>>>>> captured in the log. >>>>>>> >>>>>>> One last observation, the test that failed was running with UseZGC. >>>>>>> Not sure how that might impact this particular test. >>>>>>> >>>>>>> On 9/5/18, 2:07 PM, Chris Plummer wrote: >>>>>>>> >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>>>> >>>>>>>> The failure explanation seems to hinge on this, but I don't see >>>>>>>> how this can happen. What is resuming DebugThreadTarg? Only the >>>>>>>> call to listenUntilVMDisconnect() should be doing this, and we >>>>>>>> aren't even getting that far. The only thing I can think of is >>>>>>>> due to some other issue (maybe host out of memory so process >>>>>>>> was killed off), the DebugThreadTarg process has exited >>>>>>>> unexpectedly. In this case I guess the fix you have is >>>>>>>> appropriate defensive programming, causing the test to fail >>>>>>>> when this happens, but still won't explain why it happens and >>>>>>>> also won't prevent future failures of this test. Also, this >>>>>>>> type of Debuggee early exit problem could happen with other >>>>>>>> tests too. I'm leaning towards just closing this bug as CNR. I >>>>>>>> don't think we want to be writing our tests to defend against >>>>>>>> random system related failures, especially when the end result >>>>>>>> is still going to be a test failure that we don't fully >>>>>>>> understand. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/5/18 7:33 AM, Gary Adams wrote: >>>>>>>>> The DebuggerThreadTest ensures it is in sync >>>>>>>>> at the beginning of RunTests with a breakpoint event >>>>>>>>> in DebuggerThreadTarg ready() method. >>>>>>>>> >>>>>>>>> The DebuggerThreadTest then continues with >>>>>>>>> dumpThreads() and listenUntilVMDisconnect() >>>>>>>>> completes. >>>>>>>>> >>>>>>>>> If the DebugThreadTarg is resumed prematurely, >>>>>>>>> the main thread in the debuggee could complete >>>>>>>>> before the dumpThreads enumeration is complete. >>>>>>>>> >>>>>>>>> DebuggerThreadTest >>>>>>>>> main() >>>>>>>>> startTests() >>>>>>>>> runTests() >>>>>>>>> startTo( "DebuggerThreadTarg.ready()") >>>>>>>>> dumpThreads() >>>>>>>>> listenUntilVMDisconnect() >>>>>>>>> >>>>>>>>> DebuggerThreadTarg >>>>>>>>> main() >>>>>>>>> ready() >>>>>>>>> >>>>>>>>> Revised fix: >>>>>>>>> - Prevents the NPE from a finished thread group >>>>>>>>> - Fails the test with a message indicating >>>>>>>>> number of premature completed threads. >>>>>>>>> >>>>>>>>> diff --git a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>>> /* >>>>>>>>> - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. >>>>>>>>> All rights reserved. >>>>>>>>> + * Copyright (c) 2001, 2018, Oracle and/or its affiliates. >>>>>>>>> All rights reserved. >>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>>> * >>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>> modify it >>>>>>>>> @@ -76,8 +76,16 @@ >>>>>>>>> Thread list[] = new Thread[listThreads * 2]; >>>>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>>>> for (int i = 0; i < Math.min(gotThreads, >>>>>>>>> list.length); i++){ >>>>>>>>> + int finishedThreads = 0; >>>>>>>>> Thread t = list[i]; >>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>> + String groupName; >>>>>>>>> + if (tga == null) { >>>>>>>>> + groupName = ""; >>>>>>>>> + finishedThreads++ ; >>>>>>>>> + } else { >>>>>>>>> + groupName =tga.getName(); >>>>>>>>> + } >>>>>>>>> >>>>>>>>> System.out.println("Thread [" + i + "] group = '" + >>>>>>>>> groupName + >>>>>>>>> @@ -89,7 +97,10 @@ >>>>>>>>> failure("FAIL: non-daemon thread '" + >>>>>>>>> t.getName() + >>>>>>>>> "' found in ThreadGroup '" + >>>>>>>>> groupName + "'"); >>>>>>>>> } >>>>>>>>> - >>>>>>>>> + if (finishedThreads > 0 ) { >>>>>>>>> + failure("FAIL: " + finishedThreads + >>>>>>>>> + " threads completed while VM >>>>>>>>> suspended."); >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/4/18, 3:15 PM, Chris Plummer wrote: >>>>>>>>>> Hi Gary, >>>>>>>>>> >>>>>>>>>> The failed case only had: >>>>>>>>>> >>>>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' daemon >>>>>>>>>> = true >>>>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' daemon >>>>>>>>>> = true >>>>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = >>>>>>>>>> true >>>>>>>>>> >>>>>>>>>> That would indicate that 'main' is likely the thread that >>>>>>>>>> exited. Seems odd. Isn't that the thread that the test is >>>>>>>>>> executing in? >>>>>>>>>> >>>>>>>>>> If you can't reproduce it, maybe it would be better to commit >>>>>>>>>> a diagnostic fix like the one I suggested and keep an eye on >>>>>>>>>> it. However, it only seems to have failed once due to this >>>>>>>>>> reason, so unless it is a new problem we may never see it again. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 9/4/18 11:28 AM, Gary Adams wrote: >>>>>>>>>>> I haven't been able to reproduce the problem locally. >>>>>>>>>>> Trying larger test runs on mach5 now. >>>>>>>>>>> >>>>>>>>>>> Here's the output from a successful test run. >>>>>>>>>>> If any of the threads exited, they would have a null group >>>>>>>>>>> name. >>>>>>>>>>> >>>>>>>>>>> Howdy! >>>>>>>>>>> Thread [0] group = 'system' name = 'Reference Handler' >>>>>>>>>>> daemon = true >>>>>>>>>>> Thread [1] group = 'system' name = 'Finalizer' daemon = true >>>>>>>>>>> Thread [2] group = 'system' name = 'Signal Dispatcher' >>>>>>>>>>> daemon = true >>>>>>>>>>> Thread [3] group = 'system' name = 'process reaper' daemon = >>>>>>>>>>> true >>>>>>>>>>> Thread [4] group = 'main' name = 'main' daemon = false >>>>>>>>>>> Thread [5] group = 'main' name = 'pool-1-thread-1' daemon = >>>>>>>>>>> true >>>>>>>>>>> Thread [6] group = 'AgentVMThreadGroup' name = >>>>>>>>>>> 'AgentVMThread' daemon = false >>>>>>>>>>> Thread [7] group = 'AgentVMThreadGroup' name = 'output >>>>>>>>>>> reader' daemon = false >>>>>>>>>>> Thread [8] group = 'AgentVMThreadGroup' name = 'output >>>>>>>>>>> reader' daemon = false >>>>>>>>>>> Thread [9] group = 'AgentVMThreadGroup' name = 'Thread-5' >>>>>>>>>>> daemon = true >>>>>>>>>>> Thread [10] group = 'InnocuousThreadGroup' name = >>>>>>>>>>> 'Common-Cleaner' daemon = true >>>>>>>>>>> Thread [11] group = 'JDI [1485331767]' name = 'JDI Internal >>>>>>>>>>> Event Handler' daemon = true >>>>>>>>>>> Thread [12] group = 'JDI [1485331767]' name = 'JDI Target VM >>>>>>>>>>> Interface' daemon = true >>>>>>>>>>> Goodbye from DebuggerThreadTarg! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/4/18, 2:16 PM, Chris Plummer wrote: >>>>>>>>>>>> Can you reproduce the problem? If so, maybe to find out >>>>>>>>>>>> which thread is a problem you could check for null, print >>>>>>>>>>>> the thread info, and then fail the test. >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 9/4/18 11:14 AM, Gary Adams wrote: >>>>>>>>>>>>> I'm not sure which thread exited causes the NPE. >>>>>>>>>>>>> This patch will let the test continue and at least >>>>>>>>>>>>> let the list of threads be processed. >>>>>>>>>>>>> >>>>>>>>>>>>> The test walks up the parents to the initial thread >>>>>>>>>>>>> and then "enumerates()" the set of the threads to check. >>>>>>>>>>>>> There is an inherent race condition in enumerate() >>>>>>>>>>>>> that recognizes it is a snapshot of a moving target. >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/4/18, 1:51 PM, Chris Plummer wrote: >>>>>>>>>>>>>> Hi Gary, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why has the thread exited if the debuggee is still running? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Chris >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/4/18 5:22 AM, Gary Adams wrote: >>>>>>>>>>>>>>> Here's a quick fix to avoid the NPE using a >>>>>>>>>>>>>>> getThreadGroup() which could be null >>>>>>>>>>>>>>> if the thread has terminated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210252 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff --git >>>>>>>>>>>>>>> a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>>> b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>>> --- a/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>>> +++ b/test/jdk/com/sun/jdi/DebuggerThreadTest.java >>>>>>>>>>>>>>> @@ -77,7 +77,8 @@ >>>>>>>>>>>>>>> int gotThreads = tg.enumerate(list, true); >>>>>>>>>>>>>>> for (int i = 0; i < Math.min(gotThreads, >>>>>>>>>>>>>>> list.length); i++){ >>>>>>>>>>>>>>> Thread t = list[i]; >>>>>>>>>>>>>>> - String groupName = t.getThreadGroup().getName(); >>>>>>>>>>>>>>> + ThreadGroup tga = t.getThreadGroup(); >>>>>>>>>>>>>>> + String groupName = (tga == null ? "": >>>>>>>>>>>>>>> tga.getName()); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> System.out.println("Thread [" + i + "] >>>>>>>>>>>>>>> group = '" + >>>>>>>>>>>>>>> groupName + >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8210252.patch URL: From yasuenag at gmail.com Thu Sep 13 13:25:37 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 13 Sep 2018 22:25:37 +0900 Subject: RFR: 8209163: SA: Show Object Histogram asserts with ZGC In-Reply-To: <0a9bbe3f-63f2-9014-d279-a57312e18f31@oracle.com> References: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> <0a9bbe3f-63f2-9014-d279-a57312e18f31@oracle.com> Message-ID: Hi Per, On 2018/09/13 19:48, Per Liden wrote: > Hi JC, > > Thanks for reviewing. > > On 09/12/2018 06:02 PM, JC Beyler wrote: > > Hi Per, > > > > I do not know this code but your need to > > call?heapIterationFractionUpdate seems to be a code smell that > > something > > else could be fixed, no? > > > > Your webrev looks fine to me if I ignore the code smell that comes > > from > > having to call the update call: > > > > When I look at > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java, the > > reason it requires that first call is, like you said, that the frame > > is > > created only at the first heapIterationFractionUpdate. However, could > > we > > not test frame and if it is not created, don't try to remove it? > > I actually did that initially, but had the feeling people would think > that was an even worse code smell ;) I don't have a strong opinion on > this, so I updated the webrev to check for null instead. > > http://cr.openjdk.java.net/~pliden/8209163/webrev.1 I perfer to webrev.0 because `frame` should be initialized in ProgressiveHeapVisitor#prologue(). According to [1], HeapProgress which is used for progress bar will initialize inner frame when it is null. IMHO the inner frame should be initialized at ProgressiveHeapVisitor#prologue(). Thanks, Yasumasa [1] http://hg.openjdk.java.net/jdk/jdk/file/8abb0fa2c334/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java#l1689 > cheers, > Per > > > > > Thanks, > > Jc > > > > On Wed, Sep 12, 2018 at 1:25 AM Per Liden > > wrote: > > > > This patch avoids an assertion, and instead prints a warning, > > when > > trying to show the "Object Histogram" when using ZGC. I also had > > to add > > a call to heapIterationFractionUpdate() so that the update > > progress > > frame is properly created, even when there are not heap regions > > to walk > > over. Without this, you only get a call to > > heapIterationCompleted(), > > with a null frame, which throws a NullPointerException. Always > > making a > > call to heapIterationFractionUpdate(0.0) in the prologue avoids > > this by > > making sure we always created the frame, even if no more fraction > > updates will happen. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209163 > > Webrev: http://cr.openjdk.java.net/~pliden/8209163/webrev.0 > > > > /Per > > > > > > > > -- > > > > Thanks, > > Jc > From jcbeyler at google.com Thu Sep 13 15:39:35 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 13 Sep 2018 08:39:35 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> <2febf117-49a2-a09a-c5d9-a4bb56f111e8@oracle.com> Message-ID: My intent is to finish these macro cleanups (1 more webrev for the JNI_ENV/JVMTI_ENV in vmTestbase); then I'd like to do a webrev to remove the remaining #ifdef cplusplus from vmTestbase (another webrev). Right after that (so most likely start at some point next week), I'll start working on these two new bugs we just filed. I have to figure out how to do it semi-automatically, awk here I come again :). I got a +1 from Serguei with minor comments, with my current intent of timing Chris, do I have your LGTM for webrev.00 as is and we postpone the two nits you saw? Jc On Wed, Sep 12, 2018 at 11:16 PM Chris Plummer wrote: > I'm still not sure of your intent for when you are fixing the various > issues. I think you should commit your webrev.00 and not do all these > additional changes as part of that. > > Chris > > On 9/12/18 6:28 PM, JC Beyler wrote: > > I was going to make the changes of the incremental in the same change. > Then I'll work on the other fixes we talked about in subsequent webrevs > when I'm done with the macro refactoring. > > ie: this is my fix for the file we were talking about: > > http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp.udiff.html > > Let me know if that works for you, > Jc > > On Wed, Sep 12, 2018 at 5:28 PM Chris Plummer > wrote: > >> It looks fine, but are you going to make the incremental changes part of >> 8210665, or file a different CR for them and fix all the files under it? >> >> thanks, >> >> Chris >> >> On 9/12/18 4:30 PM, JC Beyler wrote: >> >> Yes agreed, I actually have the same preferences for indentation and >> agreed for the multi-line string literals. And for changing the ifs. I >> actually created: >> >> - Assignments in ifs: https://bugs.openjdk.java.net/browse/JDK-8210687 >> -> I've hand-waved the number with a series of greps to about 600 >> cases in vmTestbase, so except if someone has strong beliefs that they >> should not get cleaned up, we should be able to do in one-two webrevs >> -> For reference I hand-waved to 3k in src/hotspot >> >> - Multi-line string litterals: >> https://bugs.openjdk.java.net/browse/JDK-8210689 >> -> I've hand-waved the number to being 77 cases in vmTestbase, so that >> is do-able in one webrev >> -> For reference I count 6ish cases in src/hotspot >> >> Does anyone see any issues trying to handle these after the macro cleanup? >> >> For this webrev, I then offer this one, what do you think Chris? >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.02/ >> Incremental: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 >> >> Thanks all! >> Jc >> >> >> On Wed, Sep 12, 2018 at 2:09 PM Chris Plummer >> wrote: >> >>> Hi JC, >>> >>> Overall I think your proposed ji05t001.cpp changes are a good idea, but >>> I would say "assignments in an if" is the one I care about the most >>> (but others seem to disagree on this). If you think you will get around >>> to fixing "assignments in an if" soon, then I'm fine leaving out my >>> suggestion for cleaning up the one multi-line case. Otherwise I'd like to >>> see it fixed with this CR. >>> >>> Here's another issue you missed that I've fixed in the past: >>> >>> 118 NSK_DISPLAY1("%s JVMTI env: doRedirect: the JNI function table >>> obtained successfully\n\ >>> 119 \toverwriting the function GetVersion() ...\n", >>> >>> Maybe it was written before C supported concatenation of string literals. >>> >>> Also you need some consistency with the following: >>> >>> 175 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >>> ...\n", >>> 176 (indx == 0) ? "A" : "B"); >>> >>> 185 NSK_DISPLAY1("\nagent %s initializer: the JVMTI env >>> obtained\n\tsetting event callbacks ...\n", >>> 186 (indx == 0)? "A": "B"); >>> >>> I prefer the first version, indenting the arguments on the second line >>> to lineup with the first argument on the first line. I only do the latter >>> if I don't include any argument on the first line, which some times makes >>> sense if the method name is long, and possibly also is invoked using an >>> object with a long name (or is the result of a method call itself). >>> >>> thanks, >>> >>> Chris >>> >>> On 9/12/18 1:54 PM, JC Beyler wrote: >>> >>> Hi Chris, >>> >>> Thanks for the review! That remark is exactly what I was thinking for a >>> lot of these files but then this process would go even slower. A lot of the >>> coding style in these tests seem out of sync with the rest of hotspot and >>> what I would normally expect to see. I have forced myself not to touch them >>> yet and, right now, I was working at this in doing similar changes across >>> the board but keeping it simple to review. >>> >>> I (for fun?) went through ji05t001.cpp and looked quickly what I would >>> change (regardless of coding guidelines). Note the quickly, I really only >>> looked at general formatting and what we could/should perhaps do >>> automatically across the others files at some point. >>> >>> I basically noted: >>> - no {} around the body of an if, regardless if it is a one-liner >>> afterwards >>> - missing spaces before/after ==, !=, (etc), ?, : >>> - assignments in an if >>> - potentially putting back on one line when it seems still readable >>> >>> Would you have a second to look at the incremental change: >>> >>> http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00_01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/ji05t001.cpp.udiff.html >>> >>> I'm suggesting however, for this change, to do this: >>> - only apply your remark on the make the >>> >>> 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >>> ...\n", (indx==0)?"A":"B"); >>> >>> into two lines. >>> >>> And not do the other changes in this incremental to keep vmTestbase >>> relatively consistent across the board for now. >>> >>> Then, when you (and others) tell me what you think are the important >>> items of the list above and what changes were done in the incremental that >>> you think are not useful, I'll file a bug and, when done with other >>> refactoring, start hitting those (we will just need to find reviewers who >>> are willing to go through the more intense/involved webrevs). >>> >>> What do you think and thanks for your all reviews! >>> Jc >>> >>> On Wed, Sep 12, 2018 at 12:10 PM Chris Plummer >>> wrote: >>> >>>> Hi JC, >>>> >>>> Just a couple of minor suggestions in ji05t001.cpp: >>>> >>>> 174 NSK_DISPLAY1("\nagent %s initializer: obtaining the JVMTI env >>>> ...\n", (indx==0)?"A":"B"); >>>> >>>> I think I like this better as two lines. >>>> >>>> 204 if ((err = jvmti[indx]->SetEventNotificationMode(JVMTI_ENABLE, >>>> 205 JVMTI_EVENT_VM_INIT, NULL)) != JVMTI_ERROR_NONE) { /* >>>> enable event globally */ >>>> >>>> If I had my way you'd be making a couple dozen changes to remove >>>> assignments from conditional expressions, but I've been shot down when >>>> suggesting this in the past because doing this is considered within the >>>> coding guidelines. However, when the conditional takes up two lines, it >>>> really does start to become too hard to read. I'd suggest assigning "err" >>>> before the "if". >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 9/12/18 11:45 AM, JC Beyler wrote: >>>> >>>> Hi all, >>>> >>>> I am continuing the clean up of the testbase with the next batch, I >>>> know this is getting repetitive but bear with me please, after this webrev, >>>> we have in vmTestbase: >>>> >>>> - 29 more files that have the JNI_ENV* or JVMTI_ENV* macros (for a >>>> subsequent webrev) >>>> - 400+ files that have trivial #ifdef __cplusplus macros around the >>>> extern "C" and the final } (for a second subsequent webrev) >>>> >>>> After those two webrev, we can go to doing more important refactoring >>>> to get the vmTestbase in shape to start migrating out of there hopefully. >>>> >>>> So, without further ado, here is another one with 50 file changes and >>>> 1283 line changes. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210665/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210665 >>>> >>>> This passes testing for the changed tests on my dev machine. >>>> >>>> Thanks for your reviews, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 13 16:42:41 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 13 Sep 2018 09:42:41 -0700 Subject: RFR (M) 8210665: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti[R-U] tests In-Reply-To: References: <936af90f-6295-a629-5dd2-f682aa08c9ae@oracle.com> <2febf117-49a2-a09a-c5d9-a4bb56f111e8@oracle.com> Message-ID: <6ce44f3b-ded2-0300-71f4-9af57a456767@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 13 17:31:07 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 13 Sep 2018 10:31:07 -0700 Subject: RFR: 8209163: SA: Show Object Histogram asserts with ZGC In-Reply-To: References: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> <0a9bbe3f-63f2-9014-d279-a57312e18f31@oracle.com> Message-ID: Looks like webrev.0 is the good one then :); looks good to me then Per (not a reviewer though), Jc On Thu, Sep 13, 2018 at 6:25 AM Yasumasa Suenaga wrote: > Hi Per, > > On 2018/09/13 19:48, Per Liden wrote: > > Hi JC, > > > > Thanks for reviewing. > > > > On 09/12/2018 06:02 PM, JC Beyler wrote: > > > Hi Per, > > > > > > I do not know this code but your need to > > > call?heapIterationFractionUpdate seems to be a code smell that > > > something > > > else could be fixed, no? > > > > > > Your webrev looks fine to me if I ignore the code smell that comes > > > from > > > having to call the update call: > > > > > > When I look at > > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java, the > > > reason it requires that first call is, like you said, that the frame > > > is > > > created only at the first heapIterationFractionUpdate. However, could > > > we > > > not test frame and if it is not created, don't try to remove it? > > > > I actually did that initially, but had the feeling people would think > > that was an even worse code smell ;) I don't have a strong opinion on > > this, so I updated the webrev to check for null instead. > > > > http://cr.openjdk.java.net/~pliden/8209163/webrev.1 > > I perfer to webrev.0 because `frame` should be initialized in > ProgressiveHeapVisitor#prologue(). > According to [1], HeapProgress which is used for progress bar will > initialize inner frame when it is null. IMHO the inner frame should be > initialized at ProgressiveHeapVisitor#prologue(). > > > Thanks, > > Yasumasa > > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/8abb0fa2c334/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java#l1689 > > > cheers, > > Per > > > > > > > > Thanks, > > > Jc > > > > > > On Wed, Sep 12, 2018 at 1:25 AM Per Liden > > > wrote: > > > > > > This patch avoids an assertion, and instead prints a warning, > > > when > > > trying to show the "Object Histogram" when using ZGC. I also had > > > to add > > > a call to heapIterationFractionUpdate() so that the update > > > progress > > > frame is properly created, even when there are not heap regions > > > to walk > > > over. Without this, you only get a call to > > > heapIterationCompleted(), > > > with a null frame, which throws a NullPointerException. Always > > > making a > > > call to heapIterationFractionUpdate(0.0) in the prologue avoids > > > this by > > > making sure we always created the frame, even if no more fraction > > > updates will happen. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209163 > > > Webrev: http://cr.openjdk.java.net/~pliden/8209163/webrev.0 > > > > > > /Per > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 13 20:26:54 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 13 Sep 2018 13:26:54 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests Message-ID: Hi all, We have arrived to the last webrev for removing the JNI_ENV macros from the vmTestbase: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 Thanks again for the reviews, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 13 23:16:50 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 13 Sep 2018 16:16:50 -0700 Subject: RFR: JDK-8208468: [TESTBUG] nsk/jdb/locals/locals002: fails with "Prompt is not received during ... milliseconds" In-Reply-To: <0ede46ea-b952-352e-5c7d-6d91f45d47e1@oracle.com> References: <5B992262.5000509@oracle.com> <0ede46ea-b952-352e-5c7d-6d91f45d47e1@oracle.com> Message-ID: From what I can see, jdb.stdout, jdb.session, and the .jtr file all contain both the jdb output and the debuggee output. I didn't find a file that contained just the debuggee output. Have you noticed differently? Chris On 9/12/18 1:51 PM, Alex Menkov wrote: > +1 for the fix as a temporary workaround. > Actually that's look a bit strange as debuggee output is redirected. > So I'd expected it does not go through jdb log, and it should appear > in the test log with "debuggee.stdout>" prefix. > > -alex > > On 09/12/2018 12:35, Chris Plummer wrote: >> Looks good. I filed JDK-8210668 to address to root issue. >> >> Chris >> >> On 9/12/18 7:27 AM, Gary Adams wrote: >>> The print statements in the locals002 test have been observed to >>> interfere >>> with the output from commands, replies and prompts used in the >>> synchronization >>> of operations between the debugger and debuggee. This change will >>> remove the >>> print statements. A follow up bug will be filed for longer term >>> investigation of the >>> character at a time output which leaves a larger window for the >>> output interruption >>> that occurs. >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208468 >>> >>> Proposed update: >>> >>> diff --git >>> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >>> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >>> >>> --- >>> a/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >>> >>> +++ >>> b/test/hotspot/jtreg/vmTestbase/nsk/jdb/locals/locals002/locals002a.java >>> >>> @@ -81,7 +81,7 @@ >>> ??????? int[]?? arrVar >>> ?????????????????????????????? ) >>> ??? { >>> -?????? System.out.println("Arguments but no locals"); // >>> locals002.BREAKPOINT_LINE1 >>> +?????? int x = 3; // locals002.BREAKPOINT_LINE1 >>> ??? } >>> >>> ??? static void allKindsOfLocals()? { >>> @@ -97,6 +97,6 @@ >>> ??????? int[]?? arrVar??? = new int[5]; >>> >>> ??????? for (int j = 0; j < 5 ; j++) arrVar[j] = j; >>> -?????? System.out.println("Locals but no arguments"); // >>> locals002.BREAKPOINT_LINE2 >>> +?????? int x = 4; // locals002.BREAKPOINT_LINE2 >>> ??? } >>> ?} >>> >> From chris.plummer at oracle.com Thu Sep 13 23:37:48 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 13 Sep 2018 16:37:48 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: Message-ID: <9aff620a-d025-00e6-6617-ac4ce69a187c@oracle.com> Hi JC, Looks good. Just wanted to point out a couple of argument indentation choices you made that I like: ?280???? ret = jvmti->Allocate(sizeof(jvmtiThreadInfo) * threads_count, ?281?????????????????????????? (unsigned char**)&thread_info); ?304???? ret = jvmti->GetThreadListStackTraces( ?305???????? threads_count, thread_list, MAX_FRAMES_CNT, &stack_buf2); I would have done these the same way, and is what I was trying to get across as my preferred way of handling multi-line argument listsbased on what column the first argument ends up in. thanks, Chris On 9/13/18 1:26 PM, JC Beyler wrote: > Hi all, > > We have arrived to the last webrev for removing the JNI_ENV macros > from the vmTestbase: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > Thanks again for the reviews, > Jc From igor.ignatyev at oracle.com Fri Sep 14 00:07:58 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 13 Sep 2018 17:07:58 -0700 Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils Message-ID: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html > 478 lines changed: 3 ins; 319 del; 156 mod; Hi all, could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class? webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html testing: tier[1-3] + :jdk_svc,:jdk_security_infra JBS: https://bugs.openjdk.java.net/browse/JDK-8210732 Thanks, -- Igor From alexey.menkov at oracle.com Fri Sep 14 00:32:54 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 13 Sep 2018 17:32:54 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: Message-ID: Hi Jc, Some notes: <...>/MethodBind/JvmtiTest/JvmtiTest.cpp and <...>/StackTrace/JvmtiTest/JvmtiTest.cpp have several places with extra space before comma like: - ret = JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, thr), 0, max_count , stack_buffer, &count); + ret = jvmti->GetStackTrace(thr, 0, max_count , stack_buffer, &count); <...>/functions/rawmonitor/rawmonitor.cpp and <...>/timers/JvmtiTest/JvmtiTest.cpp have several suspicious changes when JVMTI_ENV_PTR and JVMTI_ENV_ARG have different arguments (that's certainly wrong, but needs to re resolved correctly): - res = JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, &main_thread)); + res = jvmti->GetCurrentThread(&main_thread); JVMTI_ENV_PTR(jvmti) is an address of the function in the vtable, and JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. So I'd expect that this should be + res = + jvmti_env->GetCurrentThread(&main_thread); Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... changes were introduced recently by the fix for "8209611: use C++ compiler for hotspot tests". /functions/rawmonitor/rawmonitor.cpp had such wrong statements before, so they should be revised carefully. AFAIU if JVMTI dunction is called from some callback where jvmtiEnv is passed, the passed value should be used. --alex On 09/13/2018 13:26, JC Beyler wrote: > Hi all, > > We have arrived to the last webrev for removing the JNI_ENV macros from > the vmTestbase: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > Thanks again for the reviews, > Jc From jcbeyler at google.com Fri Sep 14 00:37:25 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 13 Sep 2018 17:37:25 -0700 Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils In-Reply-To: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com> References: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com> Message-ID: Hi Igor, Looks good to me! Jc On Thu, Sep 13, 2018 at 5:08 PM Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html > > 478 lines changed: 3 ins; 319 del; 156 mod; > > Hi all, > > could you please review the next clean up in jdk testlibrary which removes > jdk.testlibrary.Utils class? > > webrev: > http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html > testing: tier[1-3] + :jdk_svc,:jdk_security_infra > JBS: https://bugs.openjdk.java.net/browse/JDK-8210732 > > Thanks, > -- Igor -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 14 03:05:49 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 13 Sep 2018 20:05:49 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: Message-ID: Thanks Alexey for the review, I fixed all the " ," issues that the patch changed but there are still at least 29 files that seem to have that issue in the vmTestbase that were not touched by this webrev. I imagine we can do a refactoring in another webrev (want me to file it?) or we can try to handle them when we refactor the tests to move them out of vmTestbase. The new webrev is here: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 Good catch on the change here: - res = JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, &main_thread)); + res = jvmti->GetCurrentThread(&main_thread); You are right that the change from Igor introduced this weird part where jvmti and jvmti_env are seemingly used at the same time. Turns out that for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: -#define JNI_ENV_PTR(x) x-#define JNI_ENV_ARG(x, y) y .. -#define JVMTI_ENV_PTR JNI_ENV_PTR-#define JVMTI_ENV_ARG JNI_ENV_ARG So you are right that actually it is weird but it all works out: - res = JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, &main_thread)); -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so JVMTI_ENV_PTR(jvmti) -> jvmti -> The JVMT_ENV_ARG ignores the first argument so JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread So my transformation is correct; turns out that Igor's transformation was wrong but because things were in C++, the undeclared jvmti_env was just ignored. So apart from the case where I missed something I think we are good. Let me know what you think, Jc On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov wrote: > Hi Jc, > > Some notes: > <...>/MethodBind/JvmtiTest/JvmtiTest.cpp > and > <...>/StackTrace/JvmtiTest/JvmtiTest.cpp > have several places with extra space before comma like: > - ret = JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > thr), 0, max_count , stack_buffer, &count); > + ret = jvmti->GetStackTrace(thr, 0, max_count , stack_buffer, &count); > > <...>/functions/rawmonitor/rawmonitor.cpp > and > <...>/timers/JvmtiTest/JvmtiTest.cpp > have several suspicious changes when JVMTI_ENV_PTR and JVMTI_ENV_ARG > have different arguments (that's certainly wrong, but needs to re > resolved correctly): > - res = > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > &main_thread)); > + res = jvmti->GetCurrentThread(&main_thread); > > JVMTI_ENV_PTR(jvmti) is an address of the function in the vtable, and > JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. > So I'd expect that this should be > + res = + jvmti_env->GetCurrentThread(&main_thread); > > Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like > JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... changes were > introduced recently by the fix for "8209611: use C++ compiler for > hotspot tests". > > /functions/rawmonitor/rawmonitor.cpp had such wrong statements before, > so they should be revised carefully. > AFAIU if JVMTI dunction is called from some callback where jvmtiEnv is > passed, the passed value should be used. > > --alex > > On 09/13/2018 13:26, JC Beyler wrote: > > Hi all, > > > > We have arrived to the last webrev for removing the JNI_ENV macros from > > the vmTestbase: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > > > Thanks again for the reviews, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Sep 14 06:53:27 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2018 07:53:27 +0100 Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils In-Reply-To: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com> References: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com> Message-ID: <816fb767-3bd9-7861-98f5-92a2c7aacdcd@oracle.com> On 14/09/2018 01:07, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html >> 478 lines changed: 3 ins; 319 del; 156 mod; > Hi all, > > could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class? > > webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html > testing: tier[1-3] + :jdk_svc,:jdk_security_infra > JBS: https://bugs.openjdk.java.net/browse/JDK-8210732 > Looks good and only a few remaining classes in testlibrary to move. -Alan From per.liden at oracle.com Fri Sep 14 08:23:15 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 14 Sep 2018 10:23:15 +0200 Subject: RFR: 8209163: SA: Show Object Histogram asserts with ZGC In-Reply-To: References: <90342384-6b04-353a-1ca5-6a00fb9a94ff@oracle.com> <0a9bbe3f-63f2-9014-d279-a57312e18f31@oracle.com> Message-ID: Thanks Yasumasa and JC for looking at this. I noticed that we seem to do the same thing in ReversePtrsAnalysis.java, i.e. call heapIterationFractionUpdate(0) to get things initialized. So, let's go with webrev.0. cheers, Per On 09/13/2018 07:31 PM, JC Beyler wrote: > Looks like webrev.0 is the good one then :); looks good to me then Per > (not a reviewer though), > Jc > > On Thu, Sep 13, 2018 at 6:25 AM Yasumasa Suenaga > wrote: > > Hi Per, > > On 2018/09/13 19:48, Per Liden wrote: > >? ?Hi JC, > > > >? ?Thanks for reviewing. > > > >? ?On 09/12/2018 06:02 PM, JC Beyler wrote: > >? ?> Hi Per, > >? ?> > >? ?> I do not know this code but your need to > >? ?> call?heapIterationFractionUpdate seems to be a code smell that > >? ?> something > >? ?> else could be fixed, no? > >? ?> > >? ?> Your webrev looks fine to me if I ignore the code smell that > comes > >? ?> from > >? ?> having to call the update call: > >? ?> > >? ?> When I look at > >? ?> > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java, the > >? ?> reason it requires that first call is, like you said, that > the frame > >? ?> is > >? ?> created only at the first heapIterationFractionUpdate. > However, could > >? ?> we > >? ?> not test frame and if it is not created, don't try to remove it? > > > >? ?I actually did that initially, but had the feeling people would > think > >? ?that was an even worse code smell ;) I don't have a strong > opinion on > >? ?this, so I updated the webrev to check for null instead. > > > > http://cr.openjdk.java.net/~pliden/8209163/webrev.1 > > I perfer to webrev.0 because `frame` should be initialized in > ProgressiveHeapVisitor#prologue(). > According to [1], HeapProgress which is used for progress bar will > initialize inner frame when it is null. IMHO the inner frame should > be initialized at ProgressiveHeapVisitor#prologue(). > > > Thanks, > > Yasumasa > > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/8abb0fa2c334/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java#l1689 > > >? ?cheers, > >? ?Per > > > >? ?> > >? ?> Thanks, > >? ?> Jc > >? ?> > >? ?> On Wed, Sep 12, 2018 at 1:25 AM Per Liden oracle.com > >? ?> at oracle.com > >> wrote: > >? ?> > >? ?>? ? ?This patch avoids an assertion, and instead prints a warning, > >? ?>? ? ?when > >? ?>? ? ?trying to show the "Object Histogram" when using ZGC. I > also had > >? ?>? ? ?to add > >? ?>? ? ?a call to heapIterationFractionUpdate() so that the update > >? ?>? ? ?progress > >? ?>? ? ?frame is properly created, even when there are not heap > regions > >? ?>? ? ?to walk > >? ?>? ? ?over. Without this, you only get a call to > >? ?>? ? ?heapIterationCompleted(), > >? ?>? ? ?with a null frame, which throws a NullPointerException. > Always > >? ?>? ? ?making a > >? ?>? ? ?call to heapIterationFractionUpdate(0.0) in the prologue > avoids > >? ?>? ? ?this by > >? ?>? ? ?making sure we always created the frame, even if no more > fraction > >? ?>? ? ?updates will happen. > >? ?> > >? ?>? ? ?Bug: https://bugs.openjdk.java.net/browse/JDK-8209163 > >? ?>? ? ?Webrev: http://cr.openjdk.java.net/~pliden/8209163/webrev.0 > >? ?> > >? ?>? ? ?/Per > >? ?> > >? ?> > >? ?> > >? ?> -- > >? ?> > >? ?> Thanks, > >? ?> Jc > > > > > > -- > > Thanks, > Jc From sgehwolf at redhat.com Fri Sep 14 13:33:56 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 14 Sep 2018 15:33:56 +0200 Subject: RFR: 8210647: libsaproc is being compiled without optimization. Message-ID: Hi, Could I please get a review of this one-liner fix. It changes optimization of libsaproc from -O0 to -O3 (as per Magnus' suggestion). I've run servicability tests and haven't seen any new failures. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8210647 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210647/webrev.01/ Thanks, Severin From jcbeyler at google.com Fri Sep 14 16:49:07 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 14 Sep 2018 09:49:07 -0700 Subject: RFR (XS) 8210726: Fix up a few minor nits forgotten by JDK-8210665 Message-ID: Hi all, When doing the work for JDK-8210665, I got confused with the webrevs and forgot to add Serguei's nits for the patch. I apologize for that and here they are in a separate bug. Could I get a review for it? Webrev: http://cr.openjdk.java.net/~jcbeyler/8210726/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210726 Thanks and sorry again, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 14 16:50:16 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 14 Sep 2018 09:50:16 -0700 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase Message-ID: Hi all, Could I get a review for the following webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 @Alex: I know we had said generally 50 files max but this one is really straight forward; if you still prefer 50 files, let me know and I'll cut it up into chunks. @all: A big webrev this time, to which I apologize but it is the last macro removal webrev from me in a while (there still is https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving everyone a rest on macro removal and will work on a few code refactoring I promised to do ;-)). To perhaps help reviewing it: This webrev removes two #ifdef per file touched: -#ifdef __cplusplus extern "C" { -#endif and -#ifdef __cplusplus } -#endif -> The patch only has deletions (4 per file), no insertions -> I double checked that all files only have exactly those removals and no other removals EXCEPT: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html which is still defining the NSK_STUB macros but was doing it for C/C++ styles. -> Last easier check for reviewers: - Look for deletions but that are not exactly "-#endif" or "-#ifdef __cplusplus" grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" That command provides only the lines from the nsk_tools.h file: $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) (*env)->Func(env,a,b,c,d,e,f,g) -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) (*env)->Func(env,a,b,c,d,e,f,g,h) -#ifndef NSK_CPP_STUBS_ENFORCE_C -#undef NSK_CPP_STUB1 -#undef NSK_CPP_STUB2 -#undef NSK_CPP_STUB3 -#undef NSK_CPP_STUB4 -#undef NSK_CPP_STUB5 -#undef NSK_CPP_STUB6 -#undef NSK_CPP_STUB7 -#undef NSK_CPP_STUB8 -#undef NSK_CPP_STUB9 Thanks for the reviews, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Sep 14 17:22:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Sep 2018 10:22:17 -0700 Subject: RFR: 8210647: libsaproc is being compiled without optimization. In-Reply-To: References: Message-ID: Looks good to me. /Erik On 2018-09-14 06:33, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this one-liner fix. It changes > optimization of libsaproc from -O0 to -O3 (as per Magnus' suggestion). > I've run servicability tests and haven't seen any new failures. > Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210647 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210647/webrev.01/ > > Thanks, > Severin > > From igor.ignatyev at oracle.com Fri Sep 14 17:48:33 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Sep 2018 10:48:33 -0700 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: References: Message-ID: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> Hi JC, looks good to me. (cc'ing hotspot-dev alias as it affects other teams' tests) -- Igor > On Sep 14, 2018, at 9:50 AM, JC Beyler wrote: > > Hi all, > > Could I get a review for the following webrev: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 > > @Alex: I know we had said generally 50 files max but this one is really straight forward; if you still prefer 50 files, let me know and I'll cut it up into chunks. > > @all: A big webrev this time, to which I apologize but it is the last macro removal webrev from me in a while (there still is https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving everyone a rest on macro removal and will work on a few code refactoring I promised to do ;-)). > > To perhaps help reviewing it: > This webrev removes two #ifdef per file touched: > > -#ifdef __cplusplus > extern "C" { > -#endif > > and > > -#ifdef __cplusplus > } > -#endif > > -> The patch only has deletions (4 per file), no insertions > -> I double checked that all files only have exactly those removals and no other removals EXCEPT: > http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html > which is still defining the NSK_STUB macros but was doing it for C/C++ styles. > -> Last easier check for reviewers: > - Look for deletions but that are not exactly "-#endif" or "-#ifdef __cplusplus" > grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" > > That command provides only the lines from the nsk_tools.h file: > $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" > -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) > -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) > -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) > -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) > -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) > -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) > -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) > -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) (*env)->Func(env,a,b,c,d,e,f,g) > -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) (*env)->Func(env,a,b,c,d,e,f,g,h) > -#ifndef NSK_CPP_STUBS_ENFORCE_C > -#undef NSK_CPP_STUB1 > -#undef NSK_CPP_STUB2 > -#undef NSK_CPP_STUB3 > -#undef NSK_CPP_STUB4 > -#undef NSK_CPP_STUB5 > -#undef NSK_CPP_STUB6 > -#undef NSK_CPP_STUB7 > -#undef NSK_CPP_STUB8 > -#undef NSK_CPP_STUB9 > > Thanks for the reviews, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Sep 14 17:49:36 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Sep 2018 10:49:36 -0700 Subject: RFR (XS) 8210726: Fix up a few minor nits forgotten by JDK-8210665 In-Reply-To: References: Message-ID: Hi JC, LGTM. -- Igor > On Sep 14, 2018, at 9:49 AM, JC Beyler wrote: > > Hi all, > > When doing the work for JDK-8210665, I got confused with the webrevs and forgot to add Serguei's nits for the patch. I apologize for that and here they are in a separate bug. > > Could I get a review for it? > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210726/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210726 > > Thanks and sorry again, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 14 17:52:13 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Sep 2018 10:52:13 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: Message-ID: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> Hi Jc, On 09/13/2018 20:05, JC Beyler wrote: > Thanks Alexey for the review, I fixed all the " ," issues that the patch > changed but there are still at least 29 files that seem to have that > issue in the vmTestbase that were not touched by this webrev. I imagine > we can do a refactoring in another webrev (want me to file it?) or we > can try to handle them when we refactor the tests to move them out of > vmTestbase. I don't think we need to fix this minor style issues - I asked to fix them just because your fix touches the lines. Regarding jvmti/jvmti_env mix: Looks like you are right about <...>/timers/JvmtiTest/JvmtiTest.cpp (actually if JNI_ENV_ARG didn't drop the 1st arg, the code would just fail to compile as jvmti_env is undefined in some cases). But the same issues in <...>/functions/rawmonitor/rawmonitor.cpp needs to be fixed. As I wrote before if jvmtiEnv is used in JVMTI callback, it should use jvmtiEnv passed to the callback (callback may be called on a different thread and in the case jvmti if different from jvmti_env): void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { jvmtiError res; - res = JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, &main_thread)); + res = jvmti->GetCurrentThread(&main_thread); should be + res = jvmti_env->GetCurrentThread(&main_thread); the same for other callbacks in rawmonitor.cpp --alex > > The new webrev is here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > Good catch on the change here: > -? ? res = > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > &main_thread)); > +? ? res = jvmti->GetCurrentThread(&main_thread); > > You are right that the change from Igor introduced this weird part where > jvmti and jvmti_env are seemingly used at the same time. Turns out that > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: > > -#define JNI_ENV_PTR(x) x > -#define JNI_ENV_ARG(x, y) y > > .. > > -#define JVMTI_ENV_PTR JNI_ENV_PTR > -#define JVMTI_ENV_ARG JNI_ENV_ARG > > So you are right that actually it is weird but it all works out: > > -? ? res = > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > &main_thread)); > > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so JVMTI_ENV_PTR(jvmti) -> jvmti > > -> The JVMT_ENV_ARG ignores the first argument so JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread > > So my transformation is correct; turns out that Igor's transformation was wrong but because things were in C++, > > the undeclared jvmti_env was just ignored. > > > So apart from the case where I missed something I think we are good. Let me know what you think, > > Jc > > > > > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov > wrote: > > Hi Jc, > > Some notes: > <...>/MethodBind/JvmtiTest/JvmtiTest.cpp > and > <...>/StackTrace/JvmtiTest/JvmtiTest.cpp > have several places with extra space before comma like: > -? ? ret = JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > thr), 0, max_count , stack_buffer, &count); > +? ? ret = jvmti->GetStackTrace(thr, 0, max_count , stack_buffer, > &count); > > <...>/functions/rawmonitor/rawmonitor.cpp > and > <...>/timers/JvmtiTest/JvmtiTest.cpp > have several suspicious changes when JVMTI_ENV_PTR and JVMTI_ENV_ARG > have different arguments (that's certainly wrong, but needs to re > resolved correctly): > -? ? res = > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > &main_thread)); > +? ? res = jvmti->GetCurrentThread(&main_thread); > > JVMTI_ENV_PTR(jvmti) is an address of the function in the vtable, and > JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. > So I'd expect that this should be > +? ? res = + jvmti_env->GetCurrentThread(&main_thread); > > Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like > JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... changes were > introduced recently by the fix for "8209611: use C++ compiler for > hotspot tests". > > /functions/rawmonitor/rawmonitor.cpp had such wrong statements before, > so they should be revised carefully. > AFAIU if JVMTI dunction is called from some callback where jvmtiEnv is > passed, the passed value should be used. > > --alex > > On 09/13/2018 13:26, JC Beyler wrote: > > Hi all, > > > > We have arrived to the last webrev for removing the JNI_ENV > macros from > > the vmTestbase: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > > > Thanks again for the reviews, > > Jc > > > > -- > > Thanks, > Jc From chris.plummer at oracle.com Fri Sep 14 17:54:09 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Sep 2018 10:54:09 -0700 Subject: RFR (XS) 8210726: Fix up a few minor nits forgotten by JDK-8210665 In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Sep 14 18:07:35 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Sep 2018 11:07:35 -0700 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> References: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 14 19:11:04 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 14 Sep 2018 12:11:04 -0700 Subject: RFR (XS) 8210726: Fix up a few minor nits forgotten by JDK-8210665 In-Reply-To: References: Message-ID: Hi both, Thanks for the reviews (@Chris: removed the space), Jc On Fri, Sep 14, 2018 at 10:54 AM Chris Plummer wrote: > One minor issue. There's an extra space in the following line: > > 157 fields[i].fid = env-> GetStaticFieldID(cls, > fields[i].name, fields[i].sig); > > Chris > > On 9/14/18 9:49 AM, JC Beyler wrote: > > Hi all, > > When doing the work for JDK-8210665, I got confused with the webrevs and > forgot to add Serguei's nits for the patch. I apologize for that and here > they are in a separate bug. > > Could I get a review for it? > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210726/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210726 > > Thanks and sorry again, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 14 19:59:05 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Sep 2018 12:59:05 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 Message-ID: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> Hi all, please review fix for https://bugs.openjdk.java.net/browse/JDK-8210760 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ --alex From jcbeyler at google.com Fri Sep 14 20:50:16 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 14 Sep 2018 13:50:16 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> Message-ID: Hi Alex, Ok I understand now what you mean. I just did a double check on files that had global definitions of jvmtiEnv across the tests (not complete but I looked at any file that has a grep for "^jvmtiEnv") and those were the only case where this happens. Here is a new version: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 Let me know what you think and sorry I misunderstood what you meant, Jc On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov wrote: > Hi Jc, > > On 09/13/2018 20:05, JC Beyler wrote: > > Thanks Alexey for the review, I fixed all the " ," issues that the patch > > changed but there are still at least 29 files that seem to have that > > issue in the vmTestbase that were not touched by this webrev. I imagine > > we can do a refactoring in another webrev (want me to file it?) or we > > can try to handle them when we refactor the tests to move them out of > > vmTestbase. > > I don't think we need to fix this minor style issues - I asked to fix > them just because your fix touches the lines. > > Regarding jvmti/jvmti_env mix: > Looks like you are right about <...>/timers/JvmtiTest/JvmtiTest.cpp > (actually if JNI_ENV_ARG didn't drop the 1st arg, the code would just > fail to compile as jvmti_env is undefined in some cases). > > But the same issues in <...>/functions/rawmonitor/rawmonitor.cpp needs > to be fixed. > As I wrote before if jvmtiEnv is used in JVMTI callback, it should use > jvmtiEnv passed to the callback (callback may be called on a different > thread and in the case jvmti if different from jvmti_env): > > void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { > jvmtiError res; > - res = > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > &main_thread)); > + res = jvmti->GetCurrentThread(&main_thread); > > should be > + res = jvmti_env->GetCurrentThread(&main_thread); > > the same for other callbacks in rawmonitor.cpp > > --alex > > > > > The new webrev is here: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > > > Good catch on the change here: > > - res = > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > > &main_thread)); > > + res = jvmti->GetCurrentThread(&main_thread); > > > > You are right that the change from Igor introduced this weird part where > > jvmti and jvmti_env are seemingly used at the same time. Turns out that > > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: > > > > -#define JNI_ENV_PTR(x) x > > -#define JNI_ENV_ARG(x, y) y > > > > .. > > > > -#define JVMTI_ENV_PTR JNI_ENV_PTR > > -#define JVMTI_ENV_ARG JNI_ENV_ARG > > > > So you are right that actually it is weird but it all works out: > > > > - res = > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > > &main_thread)); > > > > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so > JVMTI_ENV_PTR(jvmti) -> jvmti > > > > -> The JVMT_ENV_ARG ignores the first argument so > JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread > > > > So my transformation is correct; turns out that Igor's transformation > was wrong but because things were in C++, > > > > the undeclared jvmti_env was just ignored. > > > > > > So apart from the case where I missed something I think we are good. Let > me know what you think, > > > > Jc > > > > > > > > > > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > Some notes: > > <...>/MethodBind/JvmtiTest/JvmtiTest.cpp > > and > > <...>/StackTrace/JvmtiTest/JvmtiTest.cpp > > have several places with extra space before comma like: > > - ret = JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > > thr), 0, max_count , stack_buffer, &count); > > + ret = jvmti->GetStackTrace(thr, 0, max_count , stack_buffer, > > &count); > > > > <...>/functions/rawmonitor/rawmonitor.cpp > > and > > <...>/timers/JvmtiTest/JvmtiTest.cpp > > have several suspicious changes when JVMTI_ENV_PTR and JVMTI_ENV_ARG > > have different arguments (that's certainly wrong, but needs to re > > resolved correctly): > > - res = > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > > &main_thread)); > > + res = jvmti->GetCurrentThread(&main_thread); > > > > JVMTI_ENV_PTR(jvmti) is an address of the function in the vtable, and > > JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. > > So I'd expect that this should be > > + res = + jvmti_env->GetCurrentThread(&main_thread); > > > > Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like > > JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... changes > were > > introduced recently by the fix for "8209611: use C++ compiler for > > hotspot tests". > > > > /functions/rawmonitor/rawmonitor.cpp had such wrong statements > before, > > so they should be revised carefully. > > AFAIU if JVMTI dunction is called from some callback where jvmtiEnv > is > > passed, the passed value should be used. > > > > --alex > > > > On 09/13/2018 13:26, JC Beyler wrote: > > > Hi all, > > > > > > We have arrived to the last webrev for removing the JNI_ENV > > macros from > > > the vmTestbase: > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > > > > > Thanks again for the reviews, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Sep 14 21:01:53 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Sep 2018 14:01:53 -0700 Subject: RFR(M) : 8210732 : remove jdk.testlibrary.Utils In-Reply-To: <816fb767-3bd9-7861-98f5-92a2c7aacdcd@oracle.com> References: <6E603F2F-1162-4565-B44A-383C92980E5C@oracle.com> <816fb767-3bd9-7861-98f5-92a2c7aacdcd@oracle.com> Message-ID: Alan, JC, thank you both for review -- Igor > On Sep 13, 2018, at 11:53 PM, Alan Bateman wrote: > > > > On 14/09/2018 01:07, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html >>> 478 lines changed: 3 ins; 319 del; 156 mod; >> Hi all, >> >> could you please review the next clean up in jdk testlibrary which removes jdk.testlibrary.Utils class? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8210732/webrev.00/index.html >> testing: tier[1-3] + :jdk_svc,:jdk_security_infra >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210732 >> > Looks good and only a few remaining classes in testlibrary to move. > > -Alan From chris.plummer at oracle.com Fri Sep 14 21:27:53 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Sep 2018 14:27:53 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> Message-ID: <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> Hi Alex, Just one issue I see. For RedefineTTYLineNumber.java, the original test used to have this comment, which your removed: ? 52?? // line number sensitive!!! Next line must be line 10. It's not clear to me why this test was ever line number sensitive, and whether you removed this sensitivity, or it just never existed. In any case, you left in the following comment, which maybe should also be removed: ? 47???????? System.out.println("in A, about to call B");? // 11 before, 10 afterward Also, the println output from A() does not seem to match what the test is doing. There is no call to B(): ? 46???? public void A() { ? 47???????? System.out.println("in A, about to call B");? // 11 before, 10 afterward ? 48???????? System.out.println("out from B"); ? 49???? } Maybe that's some bit rot. My understanding of the point of the test is while at the breakpoint at the start of A(), a redefine is done that deletes a line above this point, and jdi needs to make the appropriate adjustment of the current breakpoint line number. So calling B() does not play a roll in this, but perhaps it did a one point but the call was removed. Also, I don't see any indication of line number sensitivity here, but once again, maybe this is a bit rot issue and at one point it was line number sensitive. thanks, Chris On 9/14/18 12:59 PM, Alex Menkov wrote: > Hi all, > > please review fix for > https://bugs.openjdk.java.net/browse/JDK-8210760 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ > > --alex From alexey.menkov at oracle.com Fri Sep 14 21:30:42 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Sep 2018 14:30:42 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> Message-ID: Hi Jc, I looked only at rawmonitor.cpp (I suppose nothing other has been changed). Looks good. --alex On 09/14/2018 13:50, JC Beyler wrote: > Hi Alex, > > Ok I understand now what you mean. I just did a double check on files > that had global definitions of jvmtiEnv across the tests (not complete > but I looked at any file that has a grep for "^jvmtiEnv") and those were > the only case where this happens. > > Here is a new version: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > Let me know what you think and sorry I misunderstood what you meant, > Jc > > On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov > wrote: > > Hi Jc, > > On 09/13/2018 20:05, JC Beyler wrote: > > Thanks Alexey for the review, I fixed all the " ," issues that > the patch > > changed but there are still at least 29 files that seem to have that > > issue in the vmTestbase that were not touched by this webrev. I > imagine > > we can do a refactoring in another webrev (want me to file it?) > or we > > can try to handle them when we refactor the tests to move them > out of > > vmTestbase. > > I don't think we need to fix this minor style issues - I asked to fix > them just because your fix touches the lines. > > Regarding jvmti/jvmti_env mix: > Looks like you are right about <...>/timers/JvmtiTest/JvmtiTest.cpp > (actually if JNI_ENV_ARG didn't drop the 1st arg, the code would just > fail to compile as jvmti_env is undefined in some cases). > > But the same issues in <...>/functions/rawmonitor/rawmonitor.cpp needs > to be fixed. > As I wrote before if jvmtiEnv is used in JVMTI callback, it should use > jvmtiEnv passed to the callback (callback may be called on a different > thread and in the case jvmti if different from jvmti_env): > > void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { > ? ? ? jvmtiError res; > -? ? res = > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > &main_thread)); > +? ? res = jvmti->GetCurrentThread(&main_thread); > > should be > +? ? res = jvmti_env->GetCurrentThread(&main_thread); > > the same for other callbacks in rawmonitor.cpp > > --alex > > > > > The new webrev is here: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > > > > Good catch on the change here: > > -? ? res = > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > > &main_thread)); > > +? ? res = jvmti->GetCurrentThread(&main_thread); > > > > You are right that the change from Igor introduced this weird > part where > > jvmti and jvmti_env are seemingly used at the same time. Turns > out that > > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: > > > > -#define JNI_ENV_PTR(x) x > > -#define JNI_ENV_ARG(x, y) y > > > > .. > > > > -#define JVMTI_ENV_PTR JNI_ENV_PTR > > -#define JVMTI_ENV_ARG JNI_ENV_ARG > > > > So you are right that actually it is weird but it all works out: > > > > -? ? res = > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > > &main_thread)); > > > > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so > JVMTI_ENV_PTR(jvmti) -> jvmti > > > > -> The JVMT_ENV_ARG ignores the first argument so > JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread > > > > So my transformation is correct; turns out that Igor's > transformation was wrong but because things were in C++, > > > > the undeclared jvmti_env was just ignored. > > > > > > So apart from the case where I missed something I think we are > good. Let me know what you think, > > > > Jc > > > > > > > > > > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?Some notes: > >? ? ?<...>/MethodBind/JvmtiTest/JvmtiTest.cpp > >? ? ?and > >? ? ?<...>/StackTrace/JvmtiTest/JvmtiTest.cpp > >? ? ?have several places with extra space before comma like: > >? ? ?-? ? ret = > JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > >? ? ?thr), 0, max_count , stack_buffer, &count); > >? ? ?+? ? ret = jvmti->GetStackTrace(thr, 0, max_count , stack_buffer, > >? ? ?&count); > > > >? ? ?<...>/functions/rawmonitor/rawmonitor.cpp > >? ? ?and > >? ? ?<...>/timers/JvmtiTest/JvmtiTest.cpp > >? ? ?have several suspicious changes when JVMTI_ENV_PTR and > JVMTI_ENV_ARG > >? ? ?have different arguments (that's certainly wrong, but needs to re > >? ? ?resolved correctly): > >? ? ?-? ? res = > >? ? ?JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >? ? ?&main_thread)); > >? ? ?+? ? res = jvmti->GetCurrentThread(&main_thread); > > > >? ? ?JVMTI_ENV_PTR(jvmti) is an address of the function in the > vtable, and > >? ? ?JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. > >? ? ?So I'd expect that this should be > >? ? ?+? ? res = + jvmti_env->GetCurrentThread(&main_thread); > > > >? ? ?Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like > >? ? ?JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... > changes were > >? ? ?introduced recently by the fix for "8209611: use C++ compiler for > >? ? ?hotspot tests". > > > >? ? ?/functions/rawmonitor/rawmonitor.cpp had such wrong > statements before, > >? ? ?so they should be revised carefully. > >? ? ?AFAIU if JVMTI dunction is called from some callback where > jvmtiEnv is > >? ? ?passed, the passed value should be used. > > > >? ? ?--alex > > > >? ? ?On 09/13/2018 13:26, JC Beyler wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > We have arrived to the last webrev for removing the JNI_ENV > >? ? ?macros from > >? ? ? > the vmTestbase: > >? ? ? > > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > >? ? ? > >? ? ? > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >? ? ? > > >? ? ? > Thanks again for the reviews, > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From iris.clark at oracle.com Fri Sep 14 22:01:54 2018 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 14 Sep 2018 15:01:54 -0700 (PDT) Subject: RFR (S) 8210775: JVM TI Spec missing copyright Message-ID: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> Hi. Please review the following changes to add a copyright line to the end of the generated jvmti.html file: 8210775: JVM TI Spec missing copyright bug: https://bugs.openjdk.java.net/browse/JDK-8210775 webrev: http://cr.openjdk.java.net/~iris/8210775/webrev/ The year ranges are taken from the copyright line contained within the first comment block of the source itself. These are the generated files before and after this changeset: http://cr.openjdk.java.net/~iris/8210775/jvmti-old.html http://cr.openjdk.java.net/~iris/8210775/jvmti-new.html Note that I did not add an entry to the Change History since it appears that the recent convention is to document only substantive changes to the Specification. Thanks, Iris From jcbeyler at google.com Fri Sep 14 22:03:08 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 14 Sep 2018 15:03:08 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> Message-ID: Hi Alex, I also saw two nits, in the same file as Chris was mentioning ( http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/test/jdk/com/sun/jdi/RedefineTTYLineNumber.java.udiff.html), there is a comment: // 11 before, 10 afterward That is right below, we could remove it now, no? Also in http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/test/jdk/com/sun/jdi/StringConvertTest.java.udiff.html: + // An unreported bug: this isn't handled correctly. + // If we uncomment this line, we will get an 'instance of...' line + // which will cause the test to fail. + // jdb.command(JdbCommand.print("(Object)(StringConvertTarg.x3)")); Should we perhaps file that bug now? Apart from that, looks good to me! Thanks! Jc On Fri, Sep 14, 2018 at 2:28 PM Chris Plummer wrote: > Hi Alex, > > Just one issue I see. For RedefineTTYLineNumber.java, the original test > used to have this comment, which your removed: > > 52 // line number sensitive!!! Next line must be line 10. > > It's not clear to me why this test was ever line number sensitive, and > whether you removed this sensitivity, or it just never existed. In any > case, you left in the following comment, which maybe should also be > removed: > > 47 System.out.println("in A, about to call B"); // 11 > before, 10 afterward > > Also, the println output from A() does not seem to match what the test > is doing. There is no call to B(): > > 46 public void A() { > 47 System.out.println("in A, about to call B"); // 11 > before, 10 afterward > 48 System.out.println("out from B"); > 49 } > > Maybe that's some bit rot. My understanding of the point of the test is > while at the breakpoint at the start of A(), a redefine is done that > deletes a line above this point, and jdi needs to make the appropriate > adjustment of the current breakpoint line number. So calling B() does > not play a roll in this, but perhaps it did a one point but the call was > removed. > > Also, I don't see any indication of line number sensitivity here, but > once again, maybe this is a bit rot issue and at one point it was line > number sensitive. > > thanks, > > Chris > > On 9/14/18 12:59 PM, Alex Menkov wrote: > > Hi all, > > > > please review fix for > > https://bugs.openjdk.java.net/browse/JDK-8210760 > > webrev: > > http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ > > > > --alex > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Sep 14 22:18:18 2018 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 14 Sep 2018 15:18:18 -0700 Subject: RFR (S) 8210775: JVM TI Spec missing copyright In-Reply-To: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> References: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> Message-ID: <135386bc-5a33-b655-aa0e-e0a8def9cd4f@oracle.com> On 9/14/18 3:01 PM, Iris Clark wrote: > Hi. > > Please review the following changes to add a copyright line to the end > of the generated jvmti.html file: > > 8210775: JVM TI Spec missing copyright > bug: https://bugs.openjdk.java.net/browse/JDK-8210775 > webrev: http://cr.openjdk.java.net/~iris/8210775/webrev/ This looks right to me.? The copyright line is shown in the new version. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 14 22:23:39 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Sep 2018 15:23:39 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> Message-ID: <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> Hi Chris, The file history does not contain any info about line number dependency. I'll remove "11 before, 10 afterward" comment. Actually the test is not clear to me. Accordingly the test description jdb report obsolete line number in the case, but the test does not verify its correctness, but just checks _debuggee_ (not jdb) output for absence of "Internal exception". The original bug is ancient, so it's hard to say if the test is correct or not. I can add extra testing - extract reported line numbers (by using regexp "line=(\d+)\b") and verify that 2st breakpoint is reported with the expected line number (1 less than line of the 1st breakpoint). Thoughts? --alex On 09/14/2018 14:27, Chris Plummer wrote: > Hi Alex, > > Just one issue I see. For RedefineTTYLineNumber.java, the original test > used to have this comment, which your removed: > > ? 52?? // line number sensitive!!! Next line must be line 10. > > It's not clear to me why this test was ever line number sensitive, and > whether you removed this sensitivity, or it just never existed. In any > case, you left in the following comment, which maybe should also be > removed: > > ? 47???????? System.out.println("in A, about to call B");? // 11 > before, 10 afterward > > Also, the println output from A() does not seem to match what the test > is doing. There is no call to B(): > > ? 46???? public void A() { > ? 47???????? System.out.println("in A, about to call B");? // 11 > before, 10 afterward > ? 48???????? System.out.println("out from B"); > ? 49???? } > > Maybe that's some bit rot. My understanding of the point of the test is > while at the breakpoint at the start of A(), a redefine is done that > deletes a line above this point, and jdi needs to make the appropriate > adjustment of the current breakpoint line number. So calling B() does > not play a roll in this, but perhaps it did a one point but the call was > removed. > > Also, I don't see any indication of line number sensitivity here, but > once again, maybe this is a bit rot issue and at one point it was line > number sensitive. > > thanks, > > Chris > > On 9/14/18 12:59 PM, Alex Menkov wrote: >> Hi all, >> >> please review fix for >> https://bugs.openjdk.java.net/browse/JDK-8210760 >> webrev: >> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >> >> --alex > > > From chris.plummer at oracle.com Fri Sep 14 22:32:03 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Sep 2018 15:32:03 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> Message-ID: I think checking the output after the second breakpoint would be a good idea. However, rather than checking the line number, maybe just check the contents of the line, which should be included in the breakpoint event output. Chris On 9/14/18 3:23 PM, Alex Menkov wrote: > Hi Chris, > > The file history does not contain any info about line number dependency. > I'll remove "11 before, 10 afterward" comment. > Actually the test is not clear to me. > Accordingly the test description jdb report obsolete line number in > the case, but the test does not verify its correctness, but just > checks _debuggee_ (not jdb) output for absence of "Internal exception". > The original bug is ancient, so it's hard to say if the test is > correct or not. > I can add extra testing - extract reported line numbers (by using > regexp "line=(\d+)\b") and verify that 2st breakpoint is reported with > the expected line number (1 less than line of the 1st breakpoint). > Thoughts? > > --alex > > On 09/14/2018 14:27, Chris Plummer wrote: >> Hi Alex, >> >> Just one issue I see. For RedefineTTYLineNumber.java, the original >> test used to have this comment, which your removed: >> >> ?? 52?? // line number sensitive!!! Next line must be line 10. >> >> It's not clear to me why this test was ever line number sensitive, >> and whether you removed this sensitivity, or it just never existed. >> In any case, you left in the following comment, which maybe should >> also be removed: >> >> ?? 47???????? System.out.println("in A, about to call B");? // 11 >> before, 10 afterward >> >> Also, the println output from A() does not seem to match what the >> test is doing. There is no call to B(): >> >> ?? 46???? public void A() { >> ?? 47???????? System.out.println("in A, about to call B");? // 11 >> before, 10 afterward >> ?? 48???????? System.out.println("out from B"); >> ?? 49???? } >> >> Maybe that's some bit rot. My understanding of the point of the test >> is while at the breakpoint at the start of A(), a redefine is done >> that deletes a line above this point, and jdi needs to make the >> appropriate adjustment of the current breakpoint line number. So >> calling B() does not play a roll in this, but perhaps it did a one >> point but the call was removed. >> >> Also, I don't see any indication of line number sensitivity here, but >> once again, maybe this is a bit rot issue and at one point it was >> line number sensitive. >> >> thanks, >> >> Chris >> >> On 9/14/18 12:59 PM, Alex Menkov wrote: >>> Hi all, >>> >>> please review fix for >>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>> >>> --alex >> >> >> From igor.ignatyev at oracle.com Fri Sep 14 23:09:59 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Sep 2018 16:09:59 -0700 Subject: RFR(XS) : 8210779 : 8182404 and 8210732 haven't updated copyright years Message-ID: <18029D9C-DDDF-4730-A831-B25AAD165E46@oracle.com> http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html > 36 lines changed: 0 ins; 0 del; 36 mod; Hi all, could you please review this small and trivial follow-up fix for 8182404 and 8210732? I have forgot to update copyright years as a part of these two changesets, this patch fixes that. webrev: http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210779 Thanks, -- Igor From alexey.menkov at oracle.com Fri Sep 14 23:30:05 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Sep 2018 16:30:05 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> Message-ID: On 09/14/2018 15:03, JC Beyler wrote: > Hi Alex, > > I also saw two nits, in the same file as Chris was mentioning > (http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/test/jdk/com/sun/jdi/RedefineTTYLineNumber.java.udiff.html > ), > there is a comment: > > // 11 before, 10 afterward > > That is right below, we could remove it now, no? > > > Also inhttp://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/test/jdk/com/sun/jdi/StringConvertTest.java.udiff.html > : > > + // An unreported bug: this isn't handled correctly. + // If we > uncomment this line, we will get an 'instance of...' line + // which > will cause the test to fail. + // > jdb.command(JdbCommand.print("(Object)(StringConvertTarg.x3)")); > > > Should we perhaps file that bug now? The log from 2 print calls: > print ((Object)StringConvertTarg.x3).toString() [jdb] com.sun.tools.example.debug.expr.ParseException: No instance field or method with the name toString in StringConvertTarg$JJ2[] [jdb] ((Object)StringConvertTarg.x3).toString() = null [jdb] main[1] > print (Object)(StringConvertTarg.x3) [jdb] (Object)(StringConvertTarg.x3) = instance of StringConvertTarg$JJ2[2] (id=624) [jdb] main[1] To me it looks correct as StringConvertTarg.x3 is an array. The test is for 4511950 and 4843082, there is a comment for the 2nd one: --- This fix also reverts the behavior of the command print array to the 1.4.1 behavior which is incorrect, but is better than the behavior caused by the fix for 4511950. --- So I suppose fix for 4511950 introduced some other output for arrays which was reverted later. So I think the comment may be removed. --alex > > > Apart from that, looks good to me! > > > Thanks! > > Jc > > > On Fri, Sep 14, 2018 at 2:28 PM Chris Plummer > wrote: > > Hi Alex, > > Just one issue I see. For RedefineTTYLineNumber.java, the original test > used to have this comment, which your removed: > > ?? 52?? // line number sensitive!!! Next line must be line 10. > > It's not clear to me why this test was ever line number sensitive, and > whether you removed this sensitivity, or it just never existed. In any > case, you left in the following comment, which maybe should also be > removed: > > ?? 47???????? System.out.println("in A, about to call B");? // 11 > before, 10 afterward > > Also, the println output from A() does not seem to match what the test > is doing. There is no call to B(): > > ?? 46???? public void A() { > ?? 47???????? System.out.println("in A, about to call B");? // 11 > before, 10 afterward > ?? 48???????? System.out.println("out from B"); > ?? 49???? } > > Maybe that's some bit rot. My understanding of the point of the test is > while at the breakpoint at the start of A(), a redefine is done that > deletes a line above this point, and jdi needs to make the appropriate > adjustment of the current breakpoint line number. So calling B() does > not play a roll in this, but perhaps it did a one point but the call > was > removed. > > Also, I don't see any indication of line number sensitivity here, but > once again, maybe this is a bit rot issue and at one point it was line > number sensitive. > > thanks, > > Chris > > On 9/14/18 12:59 PM, Alex Menkov wrote: > > Hi all, > > > > please review fix for > > https://bugs.openjdk.java.net/browse/JDK-8210760 > > webrev: > > http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ > > > > > --alex > > > > > > -- > > Thanks, > Jc From alexey.menkov at oracle.com Fri Sep 14 23:37:57 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 14 Sep 2018 16:37:57 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> Message-ID: <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> Looks like only line numbers are reported correctly, but the content of the line content if not correct :) [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), line=47 bci=0 [jdb] 47 System.out.println("in A, about to call B"); [jdb] [jdb] main[1] [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), line=46 bci=0 [jdb] 46 public void A() { [jdb] [jdb] main[1] "public void A()" is a line 46 in the original file --alex On 09/14/2018 15:32, Chris Plummer wrote: > I think checking the output after the second breakpoint would be a good > idea. However, rather than checking the line number, maybe just check > the contents of the line, which should be included in the breakpoint > event output. > > Chris > > On 9/14/18 3:23 PM, Alex Menkov wrote: >> Hi Chris, >> >> The file history does not contain any info about line number dependency. >> I'll remove "11 before, 10 afterward" comment. >> Actually the test is not clear to me. >> Accordingly the test description jdb report obsolete line number in >> the case, but the test does not verify its correctness, but just >> checks _debuggee_ (not jdb) output for absence of "Internal exception". >> The original bug is ancient, so it's hard to say if the test is >> correct or not. >> I can add extra testing - extract reported line numbers (by using >> regexp "line=(\d+)\b") and verify that 2st breakpoint is reported with >> the expected line number (1 less than line of the 1st breakpoint). >> Thoughts? >> >> --alex >> >> On 09/14/2018 14:27, Chris Plummer wrote: >>> Hi Alex, >>> >>> Just one issue I see. For RedefineTTYLineNumber.java, the original >>> test used to have this comment, which your removed: >>> >>> ?? 52?? // line number sensitive!!! Next line must be line 10. >>> >>> It's not clear to me why this test was ever line number sensitive, >>> and whether you removed this sensitivity, or it just never existed. >>> In any case, you left in the following comment, which maybe should >>> also be removed: >>> >>> ?? 47???????? System.out.println("in A, about to call B");? // 11 >>> before, 10 afterward >>> >>> Also, the println output from A() does not seem to match what the >>> test is doing. There is no call to B(): >>> >>> ?? 46???? public void A() { >>> ?? 47???????? System.out.println("in A, about to call B");? // 11 >>> before, 10 afterward >>> ?? 48???????? System.out.println("out from B"); >>> ?? 49???? } >>> >>> Maybe that's some bit rot. My understanding of the point of the test >>> is while at the breakpoint at the start of A(), a redefine is done >>> that deletes a line above this point, and jdi needs to make the >>> appropriate adjustment of the current breakpoint line number. So >>> calling B() does not play a roll in this, but perhaps it did a one >>> point but the call was removed. >>> >>> Also, I don't see any indication of line number sensitivity here, but >>> once again, maybe this is a bit rot issue and at one point it was >>> line number sensitive. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/14/18 12:59 PM, Alex Menkov wrote: >>>> Hi all, >>>> >>>> please review fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>>> webrev: >>>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>>> >>>> --alex >>> >>> >>> > > From brent.christian at oracle.com Sat Sep 15 00:16:26 2018 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 14 Sep 2018 17:16:26 -0700 Subject: RFR(XS) : 8210779 : 8182404 and 8210732 haven't updated copyright years In-Reply-To: <18029D9C-DDDF-4730-A831-B25AAD165E46@oracle.com> References: <18029D9C-DDDF-4730-A831-B25AAD165E46@oracle.com> Message-ID: <3446af1d-b4e5-1d47-0614-910d040e4cb1@oracle.com> Looks like you got them all - reviewed. -Brent On 09/14/2018 04:09 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html >> 36 lines changed: 0 ins; 0 del; 36 mod; > > Hi all, > > could you please review this small and trivial follow-up fix for 8182404 and 8210732? I have forgot to update copyright years as a part of these two changesets, this patch fixes that. > > webrev: http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8210779 > > Thanks, > -- Igor > From serguei.spitsyn at oracle.com Sat Sep 15 00:50:27 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Sep 2018 17:50:27 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Sep 15 01:09:45 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 14 Sep 2018 18:09:45 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> Message-ID: Hmm. I thought that's what the original bug was addressing. ? 27? * @summary TTY: Need to clear source cache after doing a redefine class Chris On 9/14/18 4:37 PM, Alex Menkov wrote: > Looks like only line numbers are reported correctly, but the content > of the line content if not correct :) > > [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), > line=47 bci=0 > [jdb] 47??????????? System.out.println("in A, about to call B"); > [jdb] > [jdb] main[1] > > [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), > line=46 bci=0 > [jdb] 46??????? public void A() { > [jdb] > [jdb] main[1] > > "public void A()" is a line 46 in the original file > > --alex > > On 09/14/2018 15:32, Chris Plummer wrote: >> I think checking the output after the second breakpoint would be a >> good idea. However, rather than checking the line number, maybe just >> check the contents of the line, which should be included in the >> breakpoint event output. >> >> Chris >> >> On 9/14/18 3:23 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> The file history does not contain any info about line number >>> dependency. >>> I'll remove "11 before, 10 afterward" comment. >>> Actually the test is not clear to me. >>> Accordingly the test description jdb report obsolete line number in >>> the case, but the test does not verify its correctness, but just >>> checks _debuggee_ (not jdb) output for absence of "Internal exception". >>> The original bug is ancient, so it's hard to say if the test is >>> correct or not. >>> I can add extra testing - extract reported line numbers (by using >>> regexp "line=(\d+)\b") and verify that 2st breakpoint is reported >>> with the expected line number (1 less than line of the 1st breakpoint). >>> Thoughts? >>> >>> --alex >>> >>> On 09/14/2018 14:27, Chris Plummer wrote: >>>> Hi Alex, >>>> >>>> Just one issue I see. For RedefineTTYLineNumber.java, the original >>>> test used to have this comment, which your removed: >>>> >>>> ?? 52?? // line number sensitive!!! Next line must be line 10. >>>> >>>> It's not clear to me why this test was ever line number sensitive, >>>> and whether you removed this sensitivity, or it just never existed. >>>> In any case, you left in the following comment, which maybe should >>>> also be removed: >>>> >>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>> before, 10 afterward >>>> >>>> Also, the println output from A() does not seem to match what the >>>> test is doing. There is no call to B(): >>>> >>>> ?? 46???? public void A() { >>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>> before, 10 afterward >>>> ?? 48???????? System.out.println("out from B"); >>>> ?? 49???? } >>>> >>>> Maybe that's some bit rot. My understanding of the point of the >>>> test is while at the breakpoint at the start of A(), a redefine is >>>> done that deletes a line above this point, and jdi needs to make >>>> the appropriate adjustment of the current breakpoint line number. >>>> So calling B() does not play a roll in this, but perhaps it did a >>>> one point but the call was removed. >>>> >>>> Also, I don't see any indication of line number sensitivity here, >>>> but once again, maybe this is a bit rot issue and at one point it >>>> was line number sensitive. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 9/14/18 12:59 PM, Alex Menkov wrote: >>>>> Hi all, >>>>> >>>>> please review fix for >>>>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>>>> >>>>> --alex >>>> >>>> >>>> >> >> From david.holmes at oracle.com Mon Sep 17 03:55:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 13:55:32 +1000 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> References: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> Message-ID: +1 from me. Thanks, David On 15/09/2018 3:48 AM, Igor Ignatyev wrote: > Hi JC, > > looks good to me. > > (cc'ing hotspot-dev alias as it affects other teams' tests) > > -- Igor > >> On Sep 14, 2018, at 9:50 AM, JC Beyler wrote: >> >> Hi all, >> >> Could I get a review for the following webrev: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 >> >> @Alex: I know we had said generally 50 files max but this one is really straight forward; if you still prefer 50 files, let me know and I'll cut it up into chunks. >> >> @all: A big webrev this time, to which I apologize but it is the last macro removal webrev from me in a while (there still is https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving everyone a rest on macro removal and will work on a few code refactoring I promised to do ;-)). >> >> To perhaps help reviewing it: >> This webrev removes two #ifdef per file touched: >> >> -#ifdef __cplusplus >> extern "C" { >> -#endif >> >> and >> >> -#ifdef __cplusplus >> } >> -#endif >> >> -> The patch only has deletions (4 per file), no insertions >> -> I double checked that all files only have exactly those removals and no other removals EXCEPT: >> http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html >> which is still defining the NSK_STUB macros but was doing it for C/C++ styles. >> -> Last easier check for reviewers: >> - Look for deletions but that are not exactly "-#endif" or "-#ifdef __cplusplus" >> grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" >> >> That command provides only the lines from the nsk_tools.h file: >> $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" >> -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) >> -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) >> -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) >> -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) >> -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) >> -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) >> -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) >> -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) (*env)->Func(env,a,b,c,d,e,f,g) >> -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) (*env)->Func(env,a,b,c,d,e,f,g,h) >> -#ifndef NSK_CPP_STUBS_ENFORCE_C >> -#undef NSK_CPP_STUB1 >> -#undef NSK_CPP_STUB2 >> -#undef NSK_CPP_STUB3 >> -#undef NSK_CPP_STUB4 >> -#undef NSK_CPP_STUB5 >> -#undef NSK_CPP_STUB6 >> -#undef NSK_CPP_STUB7 >> -#undef NSK_CPP_STUB8 >> -#undef NSK_CPP_STUB9 >> >> Thanks for the reviews, >> Jc > From jini.george at oracle.com Mon Sep 17 04:00:03 2018 From: jini.george at oracle.com (Jini George) Date: Mon, 17 Sep 2018 09:30:03 +0530 Subject: RFR: 8210647: libsaproc is being compiled without optimization. In-Reply-To: References: Message-ID: <1535943a-e733-7979-c4a7-397b7a27d6b5@oracle.com> Looks good to me. Thanks, Jini (Not a (R)eviewer) On 9/14/2018 7:03 PM, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this one-liner fix. It changes > optimization of libsaproc from -O0 to -O3 (as per Magnus' suggestion). > I've run servicability tests and haven't seen any new failures. > Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210647 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210647/webrev.01/ > > Thanks, > Severin > > From david.holmes at oracle.com Mon Sep 17 04:15:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 14:15:41 +1000 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> Message-ID: <624a30eb-503b-febb-7fb8-942e10d33024@oracle.com> I took a look at it all and it seems okay, though the use of the cached jvmtiEnv pointer did not really need to be changed. As per the spec: "JVM TI environments work across threads" The caching and its use is somewhat hard to understand without seeing where all the call paths are for the functions that still used the cached version. It would have been simpler to address the caching issue (if it needs to be addressed) separately. Cheers, David On 15/09/2018 7:30 AM, Alex Menkov wrote: > Hi Jc, > > I looked only at rawmonitor.cpp (I suppose nothing other has been changed). > Looks good. > > --alex > > On 09/14/2018 13:50, JC Beyler wrote: >> Hi Alex, >> >> Ok I understand now what you mean. I just did a double check on files >> that had global definitions of jvmtiEnv across the tests (not complete >> but I looked at any file that has a grep for "^jvmtiEnv") and those >> were the only case where this happens. >> >> Here is a new version: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 >> >> Let me know what you think and sorry I misunderstood what you meant, >> Jc >> >> On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov > > wrote: >> >> ??? Hi Jc, >> >> ??? On 09/13/2018 20:05, JC Beyler wrote: >> ???? > Thanks Alexey for the review, I fixed all the " ," issues that >> ??? the patch >> ???? > changed but there are still at least 29 files that seem to have >> that >> ???? > issue in the vmTestbase that were not touched by this webrev. I >> ??? imagine >> ???? > we can do a refactoring in another webrev (want me to file it?) >> ??? or we >> ???? > can try to handle them when we refactor the tests to move them >> ??? out of >> ???? > vmTestbase. >> >> ??? I don't think we need to fix this minor style issues - I asked to fix >> ??? them just because your fix touches the lines. >> >> ??? Regarding jvmti/jvmti_env mix: >> ??? Looks like you are right about <...>/timers/JvmtiTest/JvmtiTest.cpp >> ??? (actually if JNI_ENV_ARG didn't drop the 1st arg, the code would just >> ??? fail to compile as jvmti_env is undefined in some cases). >> >> ??? But the same issues in <...>/functions/rawmonitor/rawmonitor.cpp >> needs >> ??? to be fixed. >> ??? As I wrote before if jvmtiEnv is used in JVMTI callback, it should >> use >> ??? jvmtiEnv passed to the callback (callback may be called on a >> different >> ??? thread and in the case jvmti if different from jvmti_env): >> >> ??? void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { >> ???? ? ? ? jvmtiError res; >> ??? -? ? res = >> ??? JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ??? &main_thread)); >> ??? +? ? res = jvmti->GetCurrentThread(&main_thread); >> >> ??? should be >> ??? +? ? res = jvmti_env->GetCurrentThread(&main_thread); >> >> ??? the same for other callbacks in rawmonitor.cpp >> >> ??? --alex >> >> ???? > >> ???? > The new webrev is here: >> ???? > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ >> ??? >> ???? > >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 >> ???? > >> ???? > Good catch on the change here: >> ???? > -? ? res = >> ???? > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? > &main_thread)); >> ???? > +? ? res = jvmti->GetCurrentThread(&main_thread); >> ???? > >> ???? > You are right that the change from Igor introduced this weird >> ??? part where >> ???? > jvmti and jvmti_env are seemingly used at the same time. Turns >> ??? out that >> ???? > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: >> ???? > >> ???? > -#define JNI_ENV_PTR(x) x >> ???? > -#define JNI_ENV_ARG(x, y) y >> ???? > >> ???? > .. >> ???? > >> ???? > -#define JVMTI_ENV_PTR JNI_ENV_PTR >> ???? > -#define JVMTI_ENV_ARG JNI_ENV_ARG >> ???? > >> ???? > So you are right that actually it is weird but it all works out: >> ???? > >> ???? > -? ? res = >> ???? > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? > &main_thread)); >> ???? > >> ???? > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so >> ??? JVMTI_ENV_PTR(jvmti) -> jvmti >> ???? > >> ???? > -> The JVMT_ENV_ARG ignores the first argument so >> ??? JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread >> ???? > >> ???? > So my transformation is correct; turns out that Igor's >> ??? transformation was wrong but because things were in C++, >> ???? > >> ???? > the undeclared jvmti_env was just ignored. >> ???? > >> ???? > >> ???? > So apart from the case where I missed something I think we are >> ??? good. Let me know what you think, >> ???? > >> ???? > Jc >> ???? > >> ???? > >> ???? > >> ???? > >> ???? > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov >> ??? >> ???? > > ??? >> wrote: >> ???? > >> ???? >? ? ?Hi Jc, >> ???? > >> ???? >? ? ?Some notes: >> ???? >? ? ?<...>/MethodBind/JvmtiTest/JvmtiTest.cpp >> ???? >? ? ?and >> ???? >? ? ?<...>/StackTrace/JvmtiTest/JvmtiTest.cpp >> ???? >? ? ?have several places with extra space before comma like: >> ???? >? ? ?-? ? ret = >> ??? JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, >> ???? >? ? ?thr), 0, max_count , stack_buffer, &count); >> ???? >? ? ?+? ? ret = jvmti->GetStackTrace(thr, 0, max_count , >> stack_buffer, >> ???? >? ? ?&count); >> ???? > >> ???? >? ? ?<...>/functions/rawmonitor/rawmonitor.cpp >> ???? >? ? ?and >> ???? >? ? ?<...>/timers/JvmtiTest/JvmtiTest.cpp >> ???? >? ? ?have several suspicious changes when JVMTI_ENV_PTR and >> ??? JVMTI_ENV_ARG >> ???? >? ? ?have different arguments (that's certainly wrong, but needs >> to re >> ???? >? ? ?resolved correctly): >> ???? >? ? ?-? ? res = >> ???? > >> ?JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? >? ? ?&main_thread)); >> ???? >? ? ?+? ? res = jvmti->GetCurrentThread(&main_thread); >> ???? > >> ???? >? ? ?JVMTI_ENV_PTR(jvmti) is an address of the function in the >> ??? vtable, and >> ???? >? ? ?JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. >> ???? >? ? ?So I'd expect that this should be >> ???? >? ? ?+? ? res = + jvmti_env->GetCurrentThread(&main_thread); >> ???? > >> ???? >? ? ?Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like >> ???? >? ? ?JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... >> ??? changes were >> ???? >? ? ?introduced recently by the fix for "8209611: use C++ >> compiler for >> ???? >? ? ?hotspot tests". >> ???? > >> ???? >? ? ?/functions/rawmonitor/rawmonitor.cpp had such wrong >> ??? statements before, >> ???? >? ? ?so they should be revised carefully. >> ???? >? ? ?AFAIU if JVMTI dunction is called from some callback where >> ??? jvmtiEnv is >> ???? >? ? ?passed, the passed value should be used. >> ???? > >> ???? >? ? ?--alex >> ???? > >> ???? >? ? ?On 09/13/2018 13:26, JC Beyler wrote: >> ???? >? ? ? > Hi all, >> ???? >? ? ? > >> ???? >? ? ? > We have arrived to the last webrev for removing the JNI_ENV >> ???? >? ? ?macros from >> ???? >? ? ? > the vmTestbase: >> ???? >? ? ? > >> ???? >? ? ? > Webrev: >> ??? http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ >> ??? >> ???? >? ? ? >> ???? >? ? ? > >> ???? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 >> ???? >? ? ? > >> ???? >? ? ? > Thanks again for the reviews, >> ???? >? ? ? > Jc >> ???? > >> ???? > >> ???? > >> ???? > -- >> ???? > >> ???? > Thanks, >> ???? > Jc >> >> >> >> -- >> >> Thanks, >> Jc From sharath.ballal at oracle.com Mon Sep 17 04:25:29 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 16 Sep 2018 21:25:29 -0700 (PDT) Subject: RFR: 8210647: libsaproc is being compiled without optimization. In-Reply-To: References: Message-ID: <1f7e6594-1720-4d4a-be9e-637a4f62d50b@default> Hi Severin, Looks good to me. Thanks, Sharath (not a Reviewer) -----Original Message----- From: Severin Gehwolf [mailto:sgehwolf at redhat.com] Sent: Friday, September 14, 2018 7:04 PM To: build-dev; serviceability-dev Subject: RFR: 8210647: libsaproc is being compiled without optimization. Hi, Could I please get a review of this one-liner fix. It changes optimization of libsaproc from -O0 to -O3 (as per Magnus' suggestion). I've run servicability tests and haven't seen any new failures. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8210647 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210647/webrev.01/ Thanks, Severin From david.holmes at oracle.com Mon Sep 17 04:27:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 14:27:46 +1000 Subject: RFR (S) 8210775: JVM TI Spec missing copyright In-Reply-To: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> References: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> Message-ID: <6735ebdc-c828-91fd-9710-796be45e6f9f@oracle.com> This looks fine to me Iris. Thanks, David On 15/09/2018 8:01 AM, Iris Clark wrote: > Hi. > > Please review the following changes to add a copyright line to the end > of the generated jvmti.html file: > > 8210775: JVM TI Spec missing copyright > bug: https://bugs.openjdk.java.net/browse/JDK-8210775 > webrev: http://cr.openjdk.java.net/~iris/8210775/webrev/ > > The year ranges are taken from the copyright line contained within > the first comment block of the source itself. > > These are the generated files before and after this changeset: > > http://cr.openjdk.java.net/~iris/8210775/jvmti-old.html > http://cr.openjdk.java.net/~iris/8210775/jvmti-new.html > > Note that I did not add an entry to the Change History since it appears > that the recent convention is to document only substantive changes to > the Specification. > > Thanks, > Iris > From serguei.spitsyn at oracle.com Mon Sep 17 07:10:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 17 Sep 2018 00:10:52 -0700 Subject: RFR (XS) 8210726: Fix up a few minor nits forgotten by JDK-8210665 In-Reply-To: References: Message-ID: <29737cb4-5729-3b8f-785e-f4329f66d4c0@oracle.com> Hi Jc, +1 Thanks, Serguei On 9/14/18 10:54 AM, Chris Plummer wrote: > One minor issue. There's an extra space in the following line: > > ?157???????????? fields[i].fid = env-> GetStaticFieldID(cls, > fields[i].name, fields[i].sig); > > Chris > > On 9/14/18 9:49 AM, JC Beyler wrote: >> Hi all, >> >> When doing the work for?JDK-8210665, I got confused with the webrevs >> and forgot to add Serguei's nits for the patch. I apologize for that >> and here they are in a separate bug. >> >> Could I get a review for it? >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210726/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210726 >> >> Thanks and sorry again, >> Jc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Sep 17 07:46:23 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 17 Sep 2018 00:46:23 -0700 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: References: Message-ID: <7cdbd033-6aaa-0630-7d61-2b323143b485@oracle.com> Hi Jc, It looks good to me. Thank you for taking care about it! Thanks, Serguei On 9/14/18 9:50 AM, JC Beyler wrote: > Hi all, > > Could I get a review for the following webrev: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 > > @Alex: I know we had said generally 50 files max but this one is > really straight forward; if you still prefer 50 files, let me know and > I'll cut it up into chunks. > > @all: A big webrev this time, to which I apologize but it is the last > macro removal webrev from me in a while (there still is > https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving > everyone a rest on macro removal and will work on a few code > refactoring I promised to do ;-)). > > To perhaps help reviewing it: > This webrev removes two #ifdef per file touched: > > -#ifdef __cplusplus > ?extern "C" { > -#endif > > and > > -#ifdef __cplusplus > ?} > -#endif > > -> The patch only has deletions (4 per file), no insertions > -> I double checked that all files only have exactly those removals > and no other removals EXCEPT: > http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html > > which is still defining the NSK_STUB macros but was doing it for C/C++ > styles. > -> Last easier check for reviewers: > ? ?- Look for deletions but that are not exactly "-#endif" or "-#ifdef > __cplusplus" > grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v > "^-#ifdef __cplusplus$" > > That command provides only the lines from the nsk_tools.h file: > $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v > "^-#ifdef __cplusplus$" > -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) > -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) > -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) > -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) > -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) > -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) > -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) > -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) > (*env)->Func(env,a,b,c,d,e,f,g) > -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) > (*env)->Func(env,a,b,c,d,e,f,g,h) > -#ifndef NSK_CPP_STUBS_ENFORCE_C > -#undef NSK_CPP_STUB1 > -#undef NSK_CPP_STUB2 > -#undef NSK_CPP_STUB3 > -#undef NSK_CPP_STUB4 > -#undef NSK_CPP_STUB5 > -#undef NSK_CPP_STUB6 > -#undef NSK_CPP_STUB7 > -#undef NSK_CPP_STUB8 > -#undef NSK_CPP_STUB9 > > Thanks for the reviews, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Sep 17 07:56:53 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 17 Sep 2018 00:56:53 -0700 Subject: RFR (S) 8210775: JVM TI Spec missing copyright In-Reply-To: <6735ebdc-c828-91fd-9710-796be45e6f9f@oracle.com> References: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> <6735ebdc-c828-91fd-9710-796be45e6f9f@oracle.com> Message-ID: <15e67f59-ccce-8cb7-2a73-5f573b57fef6@oracle.com> +1 Thanks, Serguei On 9/16/18 9:27 PM, David Holmes wrote: > This looks fine to me Iris. > > Thanks, > David > > On 15/09/2018 8:01 AM, Iris Clark wrote: >> Hi. >> >> Please review the following changes to add a copyright line to the end >> of the generated jvmti.html file: >> >> ???? 8210775:? JVM TI Spec missing copyright >> ???? bug:? https://bugs.openjdk.java.net/browse/JDK-8210775 >> ???? webrev:? http://cr.openjdk.java.net/~iris/8210775/webrev/ >> >> The year ranges are taken from the copyright line contained within >> the first comment block of the source itself. >> >> These are the generated files before and after this changeset: >> >> ???? http://cr.openjdk.java.net/~iris/8210775/jvmti-old.html >> ???? http://cr.openjdk.java.net/~iris/8210775/jvmti-new.html >> >> Note that I did not add an entry to the Change History since it appears >> that the recent convention is to document only substantive changes to >> the Specification. >> >> Thanks, >> Iris >> From serguei.spitsyn at oracle.com Mon Sep 17 08:30:42 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 17 Sep 2018 01:30:42 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> Message-ID: Hi Alex, It looks good modulo the Chris's comments. Thanks, Serguei On 9/14/18 12:59 PM, Alex Menkov wrote: > Hi all, > > please review fix for > https://bugs.openjdk.java.net/browse/JDK-8210760 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ > > --alex From jcbeyler at google.com Mon Sep 17 16:14:35 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 17 Sep 2018 09:14:35 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: <624a30eb-503b-febb-7fb8-942e10d33024@oracle.com> References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> <624a30eb-503b-febb-7fb8-942e10d33024@oracle.com> Message-ID: Hi David, I think it is fine to leave the caching in the most tests I looked because they want to do JVMTI calls where there is jvmtiEnv* passed in. Would you rather I revert the rawmonitor changes to where it is still using the cached one instead of the one passed in by the call? Let me know, Jc On Sun, Sep 16, 2018 at 9:15 PM David Holmes wrote: > I took a look at it all and it seems okay, though the use of the cached > jvmtiEnv pointer did not really need to be changed. As per the spec: > > "JVM TI environments work across threads" > > The caching and its use is somewhat hard to understand without seeing > where all the call paths are for the functions that still used the > cached version. > > It would have been simpler to address the caching issue (if it needs to > be addressed) separately. > > Cheers, > David > > On 15/09/2018 7:30 AM, Alex Menkov wrote: > > Hi Jc, > > > > I looked only at rawmonitor.cpp (I suppose nothing other has been > changed). > > Looks good. > > > > --alex > > > > On 09/14/2018 13:50, JC Beyler wrote: > >> Hi Alex, > >> > >> Ok I understand now what you mean. I just did a double check on files > >> that had global definitions of jvmtiEnv across the tests (not complete > >> but I looked at any file that has a grep for "^jvmtiEnv") and those > >> were the only case where this happens. > >> > >> Here is a new version: > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> > >> Let me know what you think and sorry I misunderstood what you meant, > >> Jc > >> > >> On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov >> > wrote: > >> > >> Hi Jc, > >> > >> On 09/13/2018 20:05, JC Beyler wrote: > >> > Thanks Alexey for the review, I fixed all the " ," issues that > >> the patch > >> > changed but there are still at least 29 files that seem to have > >> that > >> > issue in the vmTestbase that were not touched by this webrev. I > >> imagine > >> > we can do a refactoring in another webrev (want me to file it?) > >> or we > >> > can try to handle them when we refactor the tests to move them > >> out of > >> > vmTestbase. > >> > >> I don't think we need to fix this minor style issues - I asked to > fix > >> them just because your fix touches the lines. > >> > >> Regarding jvmti/jvmti_env mix: > >> Looks like you are right about <...>/timers/JvmtiTest/JvmtiTest.cpp > >> (actually if JNI_ENV_ARG didn't drop the 1st arg, the code would > just > >> fail to compile as jvmti_env is undefined in some cases). > >> > >> But the same issues in <...>/functions/rawmonitor/rawmonitor.cpp > >> needs > >> to be fixed. > >> As I wrote before if jvmtiEnv is used in JVMTI callback, it should > >> use > >> jvmtiEnv passed to the callback (callback may be called on a > >> different > >> thread and in the case jvmti if different from jvmti_env): > >> > >> void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { > >> jvmtiError res; > >> - res = > >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> &main_thread)); > >> + res = jvmti->GetCurrentThread(&main_thread); > >> > >> should be > >> + res = jvmti_env->GetCurrentThread(&main_thread); > >> > >> the same for other callbacks in rawmonitor.cpp > >> > >> --alex > >> > >> > > >> > The new webrev is here: > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ > >> > >> > > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> > > >> > Good catch on the change here: > >> > - res = > >> > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> > &main_thread)); > >> > + res = jvmti->GetCurrentThread(&main_thread); > >> > > >> > You are right that the change from Igor introduced this weird > >> part where > >> > jvmti and jvmti_env are seemingly used at the same time. Turns > >> out that > >> > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: > >> > > >> > -#define JNI_ENV_PTR(x) x > >> > -#define JNI_ENV_ARG(x, y) y > >> > > >> > .. > >> > > >> > -#define JVMTI_ENV_PTR JNI_ENV_PTR > >> > -#define JVMTI_ENV_ARG JNI_ENV_ARG > >> > > >> > So you are right that actually it is weird but it all works out: > >> > > >> > - res = > >> > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> > &main_thread)); > >> > > >> > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so > >> JVMTI_ENV_PTR(jvmti) -> jvmti > >> > > >> > -> The JVMT_ENV_ARG ignores the first argument so > >> JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread > >> > > >> > So my transformation is correct; turns out that Igor's > >> transformation was wrong but because things were in C++, > >> > > >> > the undeclared jvmti_env was just ignored. > >> > > >> > > >> > So apart from the case where I missed something I think we are > >> good. Let me know what you think, > >> > > >> > Jc > >> > > >> > > >> > > >> > > >> > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov > >> > >> > >> >> wrote: > >> > > >> > Hi Jc, > >> > > >> > Some notes: > >> > <...>/MethodBind/JvmtiTest/JvmtiTest.cpp > >> > and > >> > <...>/StackTrace/JvmtiTest/JvmtiTest.cpp > >> > have several places with extra space before comma like: > >> > - ret = > >> JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > >> > thr), 0, max_count , stack_buffer, &count); > >> > + ret = jvmti->GetStackTrace(thr, 0, max_count , > >> stack_buffer, > >> > &count); > >> > > >> > <...>/functions/rawmonitor/rawmonitor.cpp > >> > and > >> > <...>/timers/JvmtiTest/JvmtiTest.cpp > >> > have several suspicious changes when JVMTI_ENV_PTR and > >> JVMTI_ENV_ARG > >> > have different arguments (that's certainly wrong, but needs > >> to re > >> > resolved correctly): > >> > - res = > >> > > >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> > &main_thread)); > >> > + res = jvmti->GetCurrentThread(&main_thread); > >> > > >> > JVMTI_ENV_PTR(jvmti) is an address of the function in the > >> vtable, and > >> > JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. > >> > So I'd expect that this should be > >> > + res = + jvmti_env->GetCurrentThread(&main_thread); > >> > > >> > Looking at timers/JvmtiTest/JvmtiTest.cpp history looks like > >> > JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... > >> changes were > >> > introduced recently by the fix for "8209611: use C++ > >> compiler for > >> > hotspot tests". > >> > > >> > /functions/rawmonitor/rawmonitor.cpp had such wrong > >> statements before, > >> > so they should be revised carefully. > >> > AFAIU if JVMTI dunction is called from some callback where > >> jvmtiEnv is > >> > passed, the passed value should be used. > >> > > >> > --alex > >> > > >> > On 09/13/2018 13:26, JC Beyler wrote: > >> > > Hi all, > >> > > > >> > > We have arrived to the last webrev for removing the > JNI_ENV > >> > macros from > >> > > the vmTestbase: > >> > > > >> > > Webrev: > >> http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > >> > >> > > >> > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/> > >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> > > > >> > > Thanks again for the reviews, > >> > > Jc > >> > > >> > > >> > > >> > -- > >> > > >> > Thanks, > >> > Jc > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris.clark at oracle.com Mon Sep 17 17:18:22 2018 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 17 Sep 2018 10:18:22 -0700 (PDT) Subject: RFR (S) 8210775: JVM TI Spec missing copyright In-Reply-To: <15e67f59-ccce-8cb7-2a73-5f573b57fef6@oracle.com> References: <20d2b5a5-a152-41ce-95af-2663b5f3cbba@default> <6735ebdc-c828-91fd-9710-796be45e6f9f@oracle.com> <15e67f59-ccce-8cb7-2a73-5f573b57fef6@oracle.com> Message-ID: Hi, Mandy, David, and Serguei. Thank you for taking the time to Review. I've pushed the changeset. iris -----Original Message----- From: Serguei Spitsyn Sent: Monday, September 17, 2018 12:57 AM To: David Holmes ; Iris Clark ; serviceability-dev Subject: Re: RFR (S) 8210775: JVM TI Spec missing copyright +1 Thanks, Serguei On 9/16/18 9:27 PM, David Holmes wrote: > This looks fine to me Iris. > > Thanks, > David > > On 15/09/2018 8:01 AM, Iris Clark wrote: >> Hi. >> >> Please review the following changes to add a copyright line to the >> end of the generated jvmti.html file: >> >> ???? 8210775:? JVM TI Spec missing copyright >> ???? bug:? https://bugs.openjdk.java.net/browse/JDK-8210775 >> ???? webrev:? http://cr.openjdk.java.net/~iris/8210775/webrev/ >> >> The year ranges are taken from the copyright line contained within >> the first comment block of the source itself. >> >> These are the generated files before and after this changeset: >> >> ???? http://cr.openjdk.java.net/~iris/8210775/jvmti-old.html >> ???? http://cr.openjdk.java.net/~iris/8210775/jvmti-new.html >> >> Note that I did not add an entry to the Change History since it >> appears that the recent convention is to document only substantive >> changes to the Specification. >> >> Thanks, >> Iris >> From alexey.menkov at oracle.com Mon Sep 17 17:49:02 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 17 Sep 2018 10:49:02 -0700 Subject: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds Message-ID: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> Hi all, please review small fix: http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ It fixes https://bugs.openjdk.java.net/browse/JDK-8210725 - accordingly the logs of the failing tests, they work as expected, but sometimes (busy environment?) there is no reply from jdb for 60 seconds, so tests throw exception. The timeout can be removed at all (so timeouts would be handled by general jtreg timeout mechanism), but prefer keep smaller timeout for jdb reply, but apply timefactor to the value. Also the change fixes https://bugs.openjdk.java.net/browse/JDK-8210748 - in the case of error additional logging is done to indicate certain point where the error occurs. --alex From jcbeyler at google.com Mon Sep 17 17:58:11 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 17 Sep 2018 10:58:11 -0700 Subject: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> Message-ID: Hi Alex, Looks good to me, Jc On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov wrote: > Hi all, > > please review small fix: > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ > > It fixes > https://bugs.openjdk.java.net/browse/JDK-8210725 > - accordingly the logs of the failing tests, they work as expected, but > sometimes (busy environment?) there is no reply from jdb for 60 seconds, > so tests throw exception. > The timeout can be removed at all (so timeouts would be handled by > general jtreg timeout mechanism), but prefer keep smaller timeout for > jdb reply, but apply timefactor to the value. > > Also the change fixes > https://bugs.openjdk.java.net/browse/JDK-8210748 > - in the case of error additional logging is done to indicate certain > point where the error occurs. > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Sep 17 18:08:37 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 17 Sep 2018 11:08:37 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> <624a30eb-503b-febb-7fb8-942e10d33024@oracle.com> Message-ID: I raised the point because I remember I saw similar issue. Finally I found the issue it and it was about JNIEnv. So there is no problem here (as tests creates only a single jvmtiEnv). Anyway I think it would be better to use jvmtiEnv passed to callbacks (then it remains correct even is other jvmtiEnv is created). --alex On 09/17/2018 09:14, JC Beyler wrote: > Hi David, > > I think it is fine to leave the caching in the most tests I looked > because they want to do JVMTI calls where there is jvmtiEnv* passed in. > Would you rather I revert the rawmonitor changes to where it is still > using the cached one instead of the one passed in by the call? > > Let me know, > Jc > > On Sun, Sep 16, 2018 at 9:15 PM David Holmes > wrote: > > I took a look at it all and it seems okay, though the use of the cached > jvmtiEnv pointer did not really need to be changed. As per the spec: > > "JVM TI environments work across threads" > > The caching and its use is somewhat hard to understand without seeing > where all the call paths are for the functions that still used the > cached version. > > It would have been simpler to address the caching issue (if it needs to > be addressed) separately. > > Cheers, > David > > On 15/09/2018 7:30 AM, Alex Menkov wrote: > > Hi Jc, > > > > I looked only at rawmonitor.cpp (I suppose nothing other has been > changed). > > Looks good. > > > > --alex > > > > On 09/14/2018 13:50, JC Beyler wrote: > >> Hi Alex, > >> > >> Ok I understand now what you mean. I just did a double check on > files > >> that had global definitions of jvmtiEnv across the tests (not > complete > >> but I looked at any file that has a grep for "^jvmtiEnv") and those > >> were the only case where this happens. > >> > >> Here is a new version: > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ > > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> > >> Let me know what you think and sorry I misunderstood what you meant, > >> Jc > >> > >> On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov > > >> >> wrote: > >> > >> ??? Hi Jc, > >> > >> ??? On 09/13/2018 20:05, JC Beyler wrote: > >> ???? > Thanks Alexey for the review, I fixed all the " ," issues > that > >> ??? the patch > >> ???? > changed but there are still at least 29 files that seem > to have > >> that > >> ???? > issue in the vmTestbase that were not touched by this > webrev. I > >> ??? imagine > >> ???? > we can do a refactoring in another webrev (want me to > file it?) > >> ??? or we > >> ???? > can try to handle them when we refactor the tests to move > them > >> ??? out of > >> ???? > vmTestbase. > >> > >> ??? I don't think we need to fix this minor style issues - I > asked to fix > >> ??? them just because your fix touches the lines. > >> > >> ??? Regarding jvmti/jvmti_env mix: > >> ??? Looks like you are right about > <...>/timers/JvmtiTest/JvmtiTest.cpp > >> ??? (actually if JNI_ENV_ARG didn't drop the 1st arg, the code > would just > >> ??? fail to compile as jvmti_env is undefined in some cases). > >> > >> ??? But the same issues in > <...>/functions/rawmonitor/rawmonitor.cpp > >> needs > >> ??? to be fixed. > >> ??? As I wrote before if jvmtiEnv is used in JVMTI callback, it > should > >> use > >> ??? jvmtiEnv passed to the callback (callback may be called on a > >> different > >> ??? thread and in the case jvmti if different from jvmti_env): > >> > >> ??? void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { > >> ???? ? ? ? jvmtiError res; > >> ??? -? ? res = > >> ??? JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> ??? &main_thread)); > >> ??? +? ? res = jvmti->GetCurrentThread(&main_thread); > >> > >> ??? should be > >> ??? +? ? res = jvmti_env->GetCurrentThread(&main_thread); > >> > >> ??? the same for other callbacks in rawmonitor.cpp > >> > >> ??? --alex > >> > >> ???? > > >> ???? > The new webrev is here: > >> ???? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ > > >> ??? > >> ???? > > >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> ???? > > >> ???? > Good catch on the change here: > >> ???? > -? ? res = > >> ???? > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> ???? > &main_thread)); > >> ???? > +? ? res = jvmti->GetCurrentThread(&main_thread); > >> ???? > > >> ???? > You are right that the change from Igor introduced this weird > >> ??? part where > >> ???? > jvmti and jvmti_env are seemingly used at the same time. > Turns > >> ??? out that > >> ???? > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: > >> ???? > > >> ???? > -#define JNI_ENV_PTR(x) x > >> ???? > -#define JNI_ENV_ARG(x, y) y > >> ???? > > >> ???? > .. > >> ???? > > >> ???? > -#define JVMTI_ENV_PTR JNI_ENV_PTR > >> ???? > -#define JVMTI_ENV_ARG JNI_ENV_ARG > >> ???? > > >> ???? > So you are right that actually it is weird but it all > works out: > >> ???? > > >> ???? > -? ? res = > >> ???? > > JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> ???? > &main_thread)); > >> ???? > > >> ???? > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so > >> ??? JVMTI_ENV_PTR(jvmti) -> jvmti > >> ???? > > >> ???? > -> The JVMT_ENV_ARG ignores the first argument so > >> ??? JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread > >> ???? > > >> ???? > So my transformation is correct; turns out that Igor's > >> ??? transformation was wrong but because things were in C++, > >> ???? > > >> ???? > the undeclared jvmti_env was just ignored. > >> ???? > > >> ???? > > >> ???? > So apart from the case where I missed something I think > we are > >> ??? good. Let me know what you think, > >> ???? > > >> ???? > Jc > >> ???? > > >> ???? > > >> ???? > > >> ???? > > >> ???? > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov > >> ??? > > > >> ???? > > >> ??? >>> wrote: > >> ???? > > >> ???? >? ? ?Hi Jc, > >> ???? > > >> ???? >? ? ?Some notes: > >> ???? >? ? ?<...>/MethodBind/JvmtiTest/JvmtiTest.cpp > >> ???? >? ? ?and > >> ???? >? ? ?<...>/StackTrace/JvmtiTest/JvmtiTest.cpp > >> ???? >? ? ?have several places with extra space before comma like: > >> ???? >? ? ?-? ? ret = > >> ??? JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > >> ???? >? ? ?thr), 0, max_count , stack_buffer, &count); > >> ???? >? ? ?+? ? ret = jvmti->GetStackTrace(thr, 0, max_count , > >> stack_buffer, > >> ???? >? ? ?&count); > >> ???? > > >> ???? >? ? ?<...>/functions/rawmonitor/rawmonitor.cpp > >> ???? >? ? ?and > >> ???? >? ? ?<...>/timers/JvmtiTest/JvmtiTest.cpp > >> ???? >? ? ?have several suspicious changes when JVMTI_ENV_PTR and > >> ??? JVMTI_ENV_ARG > >> ???? >? ? ?have different arguments (that's certainly wrong, but > needs > >> to re > >> ???? >? ? ?resolved correctly): > >> ???? >? ? ?-? ? res = > >> ???? > > >> ?JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> ???? >? ? ?&main_thread)); > >> ???? >? ? ?+? ? res = jvmti->GetCurrentThread(&main_thread); > >> ???? > > >> ???? >? ? ?JVMTI_ENV_PTR(jvmti) is an address of the function in the > >> ??? vtable, and > >> ???? >? ? ?JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. > >> ???? >? ? ?So I'd expect that this should be > >> ???? >? ? ?+? ? res = + jvmti_env->GetCurrentThread(&main_thread); > >> ???? > > >> ???? >? ? ?Looking at timers/JvmtiTest/JvmtiTest.cpp history > looks like > >> ???? >? ? ?JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... > >> ??? changes were > >> ???? >? ? ?introduced recently by the fix for "8209611: use C++ > >> compiler for > >> ???? >? ? ?hotspot tests". > >> ???? > > >> ???? >? ? ?/functions/rawmonitor/rawmonitor.cpp had such wrong > >> ??? statements before, > >> ???? >? ? ?so they should be revised carefully. > >> ???? >? ? ?AFAIU if JVMTI dunction is called from some callback > where > >> ??? jvmtiEnv is > >> ???? >? ? ?passed, the passed value should be used. > >> ???? > > >> ???? >? ? ?--alex > >> ???? > > >> ???? >? ? ?On 09/13/2018 13:26, JC Beyler wrote: > >> ???? >? ? ? > Hi all, > >> ???? >? ? ? > > >> ???? >? ? ? > We have arrived to the last webrev for removing > the JNI_ENV > >> ???? >? ? ?macros from > >> ???? >? ? ? > the vmTestbase: > >> ???? >? ? ? > > >> ???? >? ? ? > Webrev: > >> http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > > >> ??? > >> ???? > > ? > >> ???? >? ? ? > > > >> ???? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> ???? >? ? ? > > >> ???? >? ? ? > Thanks again for the reviews, > >> ???? >? ? ? > Jc > >> ???? > > >> ???? > > >> ???? > > >> ???? > -- > >> ???? > > >> ???? > Thanks, > >> ???? > Jc > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > > > > -- > > Thanks, > Jc From gary.adams at oracle.com Mon Sep 17 18:26:36 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 17 Sep 2018 14:26:36 -0400 Subject: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> Message-ID: <5B9FF1DC.40806@oracle.com> Is the log decoration typical? 98 jdb.log("======================================="); Is the Utils.adjustTimeout() applied consistently? e.g. is the timeout passed to waitFor() already adjusted? If you are promoting log() to be publicly visible, then it should be used for the other cases of println() in Jdb and JdbTest. On 9/17/18, 1:58 PM, JC Beyler wrote: > Hi Alex, > > Looks good to me, > Jc > > On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov > wrote: > > Hi all, > > please review small fix: > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ > > > It fixes > https://bugs.openjdk.java.net/browse/JDK-8210725 > - accordingly the logs of the failing tests, they work as > expected, but > sometimes (busy environment?) there is no reply from jdb for 60 > seconds, > so tests throw exception. > The timeout can be removed at all (so timeouts would be handled by > general jtreg timeout mechanism), but prefer keep smaller timeout for > jdb reply, but apply timefactor to the value. > > Also the change fixes > https://bugs.openjdk.java.net/browse/JDK-8210748 > - in the case of error additional logging is done to indicate certain > point where the error occurs. > > --alex > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Mon Sep 17 18:57:02 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 17 Sep 2018 14:57:02 -0400 Subject: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: <5B9FF1DC.40806@oracle.com> References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> <5B9FF1DC.40806@oracle.com> Message-ID: <5B9FF8FE.6060209@oracle.com> Should sleepTime also be adjusted? Should sleepTime and timeout be scoped to just waitForPrompt? On 9/17/18, 2:26 PM, Gary Adams wrote: > Is the log decoration typical? > > 98 jdb.log("======================================="); > > Is the Utils.adjustTimeout() applied consistently? > e.g. is the timeout passed to waitFor() already adjusted? > > If you are promoting log() to be publicly visible, then it > should be used for the other cases of println() in Jdb and JdbTest. > > On 9/17/18, 1:58 PM, JC Beyler wrote: >> Hi Alex, >> >> Looks good to me, >> Jc >> >> On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov >> > wrote: >> >> Hi all, >> >> please review small fix: >> http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ >> >> >> It fixes >> https://bugs.openjdk.java.net/browse/JDK-8210725 >> - accordingly the logs of the failing tests, they work as >> expected, but >> sometimes (busy environment?) there is no reply from jdb for 60 >> seconds, >> so tests throw exception. >> The timeout can be removed at all (so timeouts would be handled by >> general jtreg timeout mechanism), but prefer keep smaller timeout >> for >> jdb reply, but apply timefactor to the value. >> >> Also the change fixes >> https://bugs.openjdk.java.net/browse/JDK-8210748 >> - in the case of error additional logging is done to indicate >> certain >> point where the error occurs. >> >> --alex >> >> >> >> -- >> >> Thanks, >> Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Sep 17 19:57:06 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 17 Sep 2018 12:57:06 -0700 Subject: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: <5B9FF8FE.6060209@oracle.com> References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> <5B9FF1DC.40806@oracle.com> <5B9FF8FE.6060209@oracle.com> Message-ID: Hi Gary, updated webrev: http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.02/ see comments inline. On 09/17/2018 11:57, Gary Adams wrote: > Should sleepTime also be adjusted? No. sleepTime is delay before we read jdb output (i.e. we don't read jdb output on every update, but check for new data once a second) > > Should sleepTime and timeout be scoped to > just waitForPrompt? They are defined at the block where all constants are defined. I made the constants final. > > On 9/17/18, 2:26 PM, Gary Adams wrote: >> Is the log decoration typical? >> >> 98???????????? jdb.log("======================================="); This is to make clearer the exact point error occurs. (I initially tried just log "Exception thrown during test execution: " + e.getMessage(), but it's too inconspicuous) >> >> Is the Utils.adjustTimeout() applied consistently? >> e.g. is the timeout passed to waitFor() already adjusted? waitFor timeouts are adjusted. >> >> If you are promoting log() to be publicly visible, then it >> should be used for the other cases of println() in Jdb and JdbTest. fixed. --alex >> >> On 9/17/18, 1:58 PM, JC Beyler wrote: >>> Hi Alex, >>> >>> Looks good to me, >>> Jc >>> >>> On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov >>> > wrote: >>> >>> Hi all, >>> >>> please review small fix: >>> http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ >>> >>> >>> It fixes >>> https://bugs.openjdk.java.net/browse/JDK-8210725 >>> - accordingly the logs of the failing tests, they work as >>> expected, but >>> sometimes (busy environment?) there is no reply from jdb for 60 >>> seconds, >>> so tests throw exception. >>> The timeout can be removed at all (so timeouts would be handled by >>> general jtreg timeout mechanism), but prefer keep smaller timeout >>> for >>> jdb reply, but apply timefactor to the value. >>> >>> Also the change fixes >>> https://bugs.openjdk.java.net/browse/JDK-8210748 >>> - in the case of error additional logging is done to indicate >>> certain >>> point where the error occurs. >>> >>> --alex >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> > From david.holmes at oracle.com Mon Sep 17 22:47:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 08:47:22 +1000 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> <624a30eb-503b-febb-7fb8-942e10d33024@oracle.com> Message-ID: <5a1cfe36-6868-6b05-da38-4b1efea07115@oracle.com> I'm fine with the code the way it is. Thanks, David On 18/09/2018 4:08 AM, Alex Menkov wrote: > I raised the point because I remember I saw similar issue. > Finally I found the issue it and it was about JNIEnv. > So there is no problem here (as tests creates only a single jvmtiEnv). > Anyway I think it would be better to use jvmtiEnv passed to callbacks > (then it remains correct even is other jvmtiEnv is created). > > --alex > > On 09/17/2018 09:14, JC Beyler wrote: >> Hi David, >> >> I think it is fine to leave the caching in the most tests I looked >> because they want to do JVMTI calls where there is jvmtiEnv* passed >> in. Would you rather I revert the rawmonitor changes to where it is >> still using the cached one instead of the one passed in by the call? >> >> Let me know, >> Jc >> >> On Sun, Sep 16, 2018 at 9:15 PM David Holmes > > wrote: >> >> ??? I took a look at it all and it seems okay, though the use of the >> cached >> ??? jvmtiEnv pointer did not really need to be changed. As per the spec: >> >> ??? "JVM TI environments work across threads" >> >> ??? The caching and its use is somewhat hard to understand without seeing >> ??? where all the call paths are for the functions that still used the >> ??? cached version. >> >> ??? It would have been simpler to address the caching issue (if it >> needs to >> ??? be addressed) separately. >> >> ??? Cheers, >> ??? David >> >> ??? On 15/09/2018 7:30 AM, Alex Menkov wrote: >> ???? > Hi Jc, >> ???? > >> ???? > I looked only at rawmonitor.cpp (I suppose nothing other has been >> ??? changed). >> ???? > Looks good. >> ???? > >> ???? > --alex >> ???? > >> ???? > On 09/14/2018 13:50, JC Beyler wrote: >> ???? >> Hi Alex, >> ???? >> >> ???? >> Ok I understand now what you mean. I just did a double check on >> ??? files >> ???? >> that had global definitions of jvmtiEnv across the tests (not >> ??? complete >> ???? >> but I looked at any file that has a grep for "^jvmtiEnv") and >> those >> ???? >> were the only case where this happens. >> ???? >> >> ???? >> Here is a new version: >> ???? >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ >> ??? >> ???? >> >> ???? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 >> ???? >> >> ???? >> Let me know what you think and sorry I misunderstood what you >> meant, >> ???? >> Jc >> ???? >> >> ???? >> On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov >> ??? >> ???? >> > ??? >> wrote: >> ???? >> >> ???? >> ??? Hi Jc, >> ???? >> >> ???? >> ??? On 09/13/2018 20:05, JC Beyler wrote: >> ???? >> ???? > Thanks Alexey for the review, I fixed all the " ," issues >> ??? that >> ???? >> ??? the patch >> ???? >> ???? > changed but there are still at least 29 files that seem >> ??? to have >> ???? >> that >> ???? >> ???? > issue in the vmTestbase that were not touched by this >> ??? webrev. I >> ???? >> ??? imagine >> ???? >> ???? > we can do a refactoring in another webrev (want me to >> ??? file it?) >> ???? >> ??? or we >> ???? >> ???? > can try to handle them when we refactor the tests to move >> ??? them >> ???? >> ??? out of >> ???? >> ???? > vmTestbase. >> ???? >> >> ???? >> ??? I don't think we need to fix this minor style issues - I >> ??? asked to fix >> ???? >> ??? them just because your fix touches the lines. >> ???? >> >> ???? >> ??? Regarding jvmti/jvmti_env mix: >> ???? >> ??? Looks like you are right about >> ??? <...>/timers/JvmtiTest/JvmtiTest.cpp >> ???? >> ??? (actually if JNI_ENV_ARG didn't drop the 1st arg, the code >> ??? would just >> ???? >> ??? fail to compile as jvmti_env is undefined in some cases). >> ???? >> >> ???? >> ??? But the same issues in >> ??? <...>/functions/rawmonitor/rawmonitor.cpp >> ???? >> needs >> ???? >> ??? to be fixed. >> ???? >> ??? As I wrote before if jvmtiEnv is used in JVMTI callback, it >> ??? should >> ???? >> use >> ???? >> ??? jvmtiEnv passed to the callback (callback may be called on a >> ???? >> different >> ???? >> ??? thread and in the case jvmti if different from jvmti_env): >> ???? >> >> ???? >> ??? void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { >> ???? >> ???? ? ? ? jvmtiError res; >> ???? >> ??? -? ? res = >> ???? >> >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? >> ??? &main_thread)); >> ???? >> ??? +? ? res = jvmti->GetCurrentThread(&main_thread); >> ???? >> >> ???? >> ??? should be >> ???? >> ??? +? ? res = jvmti_env->GetCurrentThread(&main_thread); >> ???? >> >> ???? >> ??? the same for other callbacks in rawmonitor.cpp >> ???? >> >> ???? >> ??? --alex >> ???? >> >> ???? >> ???? > >> ???? >> ???? > The new webrev is here: >> ???? >> ???? > Webrev: >> ??? http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ >> ??? >> ???? >> ??? >> ???? >> ???? > >> >> ???? >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 >> ???? >> ???? > >> ???? >> ???? > Good catch on the change here: >> ???? >> ???? > -? ? res = >> ???? >> ???? > >> ??? JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? >> ???? > &main_thread)); >> ???? >> ???? > +? ? res = jvmti->GetCurrentThread(&main_thread); >> ???? >> ???? > >> ???? >> ???? > You are right that the change from Igor introduced this >> weird >> ???? >> ??? part where >> ???? >> ???? > jvmti and jvmti_env are seemingly used at the same time. >> ??? Turns >> ???? >> ??? out that >> ???? >> ???? > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: >> ???? >> ???? > >> ???? >> ???? > -#define JNI_ENV_PTR(x) x >> ???? >> ???? > -#define JNI_ENV_ARG(x, y) y >> ???? >> ???? > >> ???? >> ???? > .. >> ???? >> ???? > >> ???? >> ???? > -#define JVMTI_ENV_PTR JNI_ENV_PTR >> ???? >> ???? > -#define JVMTI_ENV_ARG JNI_ENV_ARG >> ???? >> ???? > >> ???? >> ???? > So you are right that actually it is weird but it all >> ??? works out: >> ???? >> ???? > >> ???? >> ???? > -? ? res = >> ???? >> ???? > >> ??? JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? >> ???? > &main_thread)); >> ???? >> ???? > >> ???? >> ???? > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so >> ???? >> ??? JVMTI_ENV_PTR(jvmti) -> jvmti >> ???? >> ???? > >> ???? >> ???? > -> The JVMT_ENV_ARG ignores the first argument so >> ???? >> ??? JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread >> ???? >> ???? > >> ???? >> ???? > So my transformation is correct; turns out that Igor's >> ???? >> ??? transformation was wrong but because things were in C++, >> ???? >> ???? > >> ???? >> ???? > the undeclared jvmti_env was just ignored. >> ???? >> ???? > >> ???? >> ???? > >> ???? >> ???? > So apart from the case where I missed something I think >> ??? we are >> ???? >> ??? good. Let me know what you think, >> ???? >> ???? > >> ???? >> ???? > Jc >> ???? >> ???? > >> ???? >> ???? > >> ???? >> ???? > >> ???? >> ???? > >> ???? >> ???? > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov >> ???? >> ??? >> ??? > >> ???? >> ???? > > ??? >> ???? >> ??? > ??? >>> wrote: >> ???? >> ???? > >> ???? >> ???? >? ? ?Hi Jc, >> ???? >> ???? > >> ???? >> ???? >? ? ?Some notes: >> ???? >> ???? >? ? ?<...>/MethodBind/JvmtiTest/JvmtiTest.cpp >> ???? >> ???? >? ? ?and >> ???? >> ???? >? ? ?<...>/StackTrace/JvmtiTest/JvmtiTest.cpp >> ???? >> ???? >? ? ?have several places with extra space before comma >> like: >> ???? >> ???? >? ? ?-? ? ret = >> ???? >> ??? JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, >> ???? >> ???? >? ? ?thr), 0, max_count , stack_buffer, &count); >> ???? >> ???? >? ? ?+? ? ret = jvmti->GetStackTrace(thr, 0, max_count , >> ???? >> stack_buffer, >> ???? >> ???? >? ? ?&count); >> ???? >> ???? > >> ???? >> ???? >? ? ?<...>/functions/rawmonitor/rawmonitor.cpp >> ???? >> ???? >? ? ?and >> ???? >> ???? >? ? ?<...>/timers/JvmtiTest/JvmtiTest.cpp >> ???? >> ???? >? ? ?have several suspicious changes when JVMTI_ENV_PTR and >> ???? >> ??? JVMTI_ENV_ARG >> ???? >> ???? >? ? ?have different arguments (that's certainly wrong, but >> ??? needs >> ???? >> to re >> ???? >> ???? >? ? ?resolved correctly): >> ???? >> ???? >? ? ?-? ? res = >> ???? >> ???? > >> ???? >> ?JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, >> ???? >> ???? >? ? ?&main_thread)); >> ???? >> ???? >? ? ?+? ? res = jvmti->GetCurrentThread(&main_thread); >> ???? >> ???? > >> ???? >> ???? >? ? ?JVMTI_ENV_PTR(jvmti) is an address of the function >> in the >> ???? >> ??? vtable, and >> ???? >> ???? >? ? ?JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer. >> ???? >> ???? >? ? ?So I'd expect that this should be >> ???? >> ???? >? ? ?+? ? res = + >> jvmti_env->GetCurrentThread(&main_thread); >> ???? >> ???? > >> ???? >> ???? >? ? ?Looking at timers/JvmtiTest/JvmtiTest.cpp history >> ??? looks like >> ???? >> ???? > >> ?JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... >> ???? >> ??? changes were >> ???? >> ???? >? ? ?introduced recently by the fix for "8209611: use C++ >> ???? >> compiler for >> ???? >> ???? >? ? ?hotspot tests". >> ???? >> ???? > >> ???? >> ???? >? ? ?/functions/rawmonitor/rawmonitor.cpp had such wrong >> ???? >> ??? statements before, >> ???? >> ???? >? ? ?so they should be revised carefully. >> ???? >> ???? >? ? ?AFAIU if JVMTI dunction is called from some callback >> ??? where >> ???? >> ??? jvmtiEnv is >> ???? >> ???? >? ? ?passed, the passed value should be used. >> ???? >> ???? > >> ???? >> ???? >? ? ?--alex >> ???? >> ???? > >> ???? >> ???? >? ? ?On 09/13/2018 13:26, JC Beyler wrote: >> ???? >> ???? >? ? ? > Hi all, >> ???? >> ???? >? ? ? > >> ???? >> ???? >? ? ? > We have arrived to the last webrev for removing >> ??? the JNI_ENV >> ???? >> ???? >? ? ?macros from >> ???? >> ???? >? ? ? > the vmTestbase: >> ???? >> ???? >? ? ? > >> ???? >> ???? >? ? ? > Webrev: >> ???? >> http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ >> ??? >> ???? >> ??? >> ???? >> ???? > >> ? >> ???? >> ???? >? ? ? > >> ??? >> ???? >> ???? >? ? ? > Bug: >> https://bugs.openjdk.java.net/browse/JDK-8210700 >> ???? >> ???? >? ? ? > >> ???? >> ???? >? ? ? > Thanks again for the reviews, >> ???? >> ???? >? ? ? > Jc >> ???? >> ???? > >> ???? >> ???? > >> ???? >> ???? > >> ???? >> ???? > -- >> ???? >> ???? > >> ???? >> ???? > Thanks, >> ???? >> ???? > Jc >> ???? >> >> ???? >> >> ???? >> >> ???? >> -- >> ???? >> >> ???? >> Thanks, >> ???? >> Jc >> >> >> >> -- >> >> Thanks, >> Jc From jcbeyler at google.com Tue Sep 18 02:38:08 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 17 Sep 2018 19:38:08 -0700 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: <7cdbd033-6aaa-0630-7d61-2b323143b485@oracle.com> References: <7cdbd033-6aaa-0630-7d61-2b323143b485@oracle.com> Message-ID: Thanks all for the reviews, I know it was a bit big and tedious; this is pushed :) Jc On Mon, Sep 17, 2018 at 12:46 AM wrote: > Hi Jc, > > It looks good to me. > Thank you for taking care about it! > > Thanks, > Serguei > > > > On 9/14/18 9:50 AM, JC Beyler wrote: > > Hi all, > > Could I get a review for the following webrev: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 > > @Alex: I know we had said generally 50 files max but this one is really > straight forward; if you still prefer 50 files, let me know and I'll cut it > up into chunks. > > @all: A big webrev this time, to which I apologize but it is the last > macro removal webrev from me in a while (there still is > https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving everyone > a rest on macro removal and will work on a few code refactoring I promised > to do ;-)). > > To perhaps help reviewing it: > This webrev removes two #ifdef per file touched: > > -#ifdef __cplusplus > extern "C" { > -#endif > > and > > -#ifdef __cplusplus > } > -#endif > > -> The patch only has deletions (4 per file), no insertions > -> I double checked that all files only have exactly those removals and no > other removals EXCEPT: > > http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html > which is still defining the NSK_STUB macros but was doing it for C/C++ > styles. > -> Last easier check for reviewers: > - Look for deletions but that are not exactly "-#endif" or "-#ifdef > __cplusplus" > grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v > "^-#ifdef __cplusplus$" > > That command provides only the lines from the nsk_tools.h file: > $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v > "^-#ifdef __cplusplus$" > -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) > -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) > -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) > -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) > -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) > -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) > -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) > -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) > (*env)->Func(env,a,b,c,d,e,f,g) > -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) > (*env)->Func(env,a,b,c,d,e,f,g,h) > -#ifndef NSK_CPP_STUBS_ENFORCE_C > -#undef NSK_CPP_STUB1 > -#undef NSK_CPP_STUB2 > -#undef NSK_CPP_STUB3 > -#undef NSK_CPP_STUB4 > -#undef NSK_CPP_STUB5 > -#undef NSK_CPP_STUB6 > -#undef NSK_CPP_STUB7 > -#undef NSK_CPP_STUB8 > -#undef NSK_CPP_STUB9 > > Thanks for the reviews, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Sep 18 02:51:35 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 17 Sep 2018 19:51:35 -0700 Subject: RFR (M) 8210700: Clean up JNI_ENV_ARG and factorize the macros for vmTestbase/jvmti/unit tests In-Reply-To: <5a1cfe36-6868-6b05-da38-4b1efea07115@oracle.com> References: <3053053a-cc40-65a9-ea3e-cc8eb1f717e2@oracle.com> <624a30eb-503b-febb-7fb8-942e10d33024@oracle.com> <5a1cfe36-6868-6b05-da38-4b1efea07115@oracle.com> Message-ID: Hi all, Thanks David, I pushed the webrev after re-testing the unit subtests. Have all a great evening, Jc On Mon, Sep 17, 2018 at 3:47 PM David Holmes wrote: > I'm fine with the code the way it is. > > Thanks, > David > > On 18/09/2018 4:08 AM, Alex Menkov wrote: > > I raised the point because I remember I saw similar issue. > > Finally I found the issue it and it was about JNIEnv. > > So there is no problem here (as tests creates only a single jvmtiEnv). > > Anyway I think it would be better to use jvmtiEnv passed to callbacks > > (then it remains correct even is other jvmtiEnv is created). > > > > --alex > > > > On 09/17/2018 09:14, JC Beyler wrote: > >> Hi David, > >> > >> I think it is fine to leave the caching in the most tests I looked > >> because they want to do JVMTI calls where there is jvmtiEnv* passed > >> in. Would you rather I revert the rawmonitor changes to where it is > >> still using the cached one instead of the one passed in by the call? > >> > >> Let me know, > >> Jc > >> > >> On Sun, Sep 16, 2018 at 9:15 PM David Holmes >> > wrote: > >> > >> I took a look at it all and it seems okay, though the use of the > >> cached > >> jvmtiEnv pointer did not really need to be changed. As per the spec: > >> > >> "JVM TI environments work across threads" > >> > >> The caching and its use is somewhat hard to understand without > seeing > >> where all the call paths are for the functions that still used the > >> cached version. > >> > >> It would have been simpler to address the caching issue (if it > >> needs to > >> be addressed) separately. > >> > >> Cheers, > >> David > >> > >> On 15/09/2018 7:30 AM, Alex Menkov wrote: > >> > Hi Jc, > >> > > >> > I looked only at rawmonitor.cpp (I suppose nothing other has been > >> changed). > >> > Looks good. > >> > > >> > --alex > >> > > >> > On 09/14/2018 13:50, JC Beyler wrote: > >> >> Hi Alex, > >> >> > >> >> Ok I understand now what you mean. I just did a double check on > >> files > >> >> that had global definitions of jvmtiEnv across the tests (not > >> complete > >> >> but I looked at any file that has a grep for "^jvmtiEnv") and > >> those > >> >> were the only case where this happens. > >> >> > >> >> Here is a new version: > >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/ > >> > >> >> > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> >> > >> >> Let me know what you think and sorry I misunderstood what you > >> meant, > >> >> Jc > >> >> > >> >> On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov > >> > >> >> >> >> wrote: > >> >> > >> >> Hi Jc, > >> >> > >> >> On 09/13/2018 20:05, JC Beyler wrote: > >> >> > Thanks Alexey for the review, I fixed all the " ," issues > >> that > >> >> the patch > >> >> > changed but there are still at least 29 files that seem > >> to have > >> >> that > >> >> > issue in the vmTestbase that were not touched by this > >> webrev. I > >> >> imagine > >> >> > we can do a refactoring in another webrev (want me to > >> file it?) > >> >> or we > >> >> > can try to handle them when we refactor the tests to move > >> them > >> >> out of > >> >> > vmTestbase. > >> >> > >> >> I don't think we need to fix this minor style issues - I > >> asked to fix > >> >> them just because your fix touches the lines. > >> >> > >> >> Regarding jvmti/jvmti_env mix: > >> >> Looks like you are right about > >> <...>/timers/JvmtiTest/JvmtiTest.cpp > >> >> (actually if JNI_ENV_ARG didn't drop the 1st arg, the code > >> would just > >> >> fail to compile as jvmti_env is undefined in some cases). > >> >> > >> >> But the same issues in > >> <...>/functions/rawmonitor/rawmonitor.cpp > >> >> needs > >> >> to be fixed. > >> >> As I wrote before if jvmtiEnv is used in JVMTI callback, it > >> should > >> >> use > >> >> jvmtiEnv passed to the callback (callback may be called on a > >> >> different > >> >> thread and in the case jvmti if different from jvmti_env): > >> >> > >> >> void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) { > >> >> jvmtiError res; > >> >> - res = > >> >> > >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> >> &main_thread)); > >> >> + res = jvmti->GetCurrentThread(&main_thread); > >> >> > >> >> should be > >> >> + res = jvmti_env->GetCurrentThread(&main_thread); > >> >> > >> >> the same for other callbacks in rawmonitor.cpp > >> >> > >> >> --alex > >> >> > >> >> > > >> >> > The new webrev is here: > >> >> > Webrev: > >> http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/ > >> > >> >> > >> >> > > >> > >> >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210700 > >> >> > > >> >> > Good catch on the change here: > >> >> > - res = > >> >> > > >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> >> > &main_thread)); > >> >> > + res = jvmti->GetCurrentThread(&main_thread); > >> >> > > >> >> > You are right that the change from Igor introduced this > >> weird > >> >> part where > >> >> > jvmti and jvmti_env are seemingly used at the same time. > >> Turns > >> >> out that > >> >> > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into: > >> >> > > >> >> > -#define JNI_ENV_PTR(x) x > >> >> > -#define JNI_ENV_ARG(x, y) y > >> >> > > >> >> > .. > >> >> > > >> >> > -#define JVMTI_ENV_PTR JNI_ENV_PTR > >> >> > -#define JVMTI_ENV_ARG JNI_ENV_ARG > >> >> > > >> >> > So you are right that actually it is weird but it all > >> works out: > >> >> > > >> >> > - res = > >> >> > > >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> >> > &main_thread)); > >> >> > > >> >> > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so > >> >> JVMTI_ENV_PTR(jvmti) -> jvmti > >> >> > > >> >> > -> The JVMT_ENV_ARG ignores the first argument so > >> >> JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread > >> >> > > >> >> > So my transformation is correct; turns out that Igor's > >> >> transformation was wrong but because things were in C++, > >> >> > > >> >> > the undeclared jvmti_env was just ignored. > >> >> > > >> >> > > >> >> > So apart from the case where I missed something I think > >> we are > >> >> good. Let me know what you think, > >> >> > > >> >> > Jc > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov > >> >> > >> > > >> >> > >> > >> >> >> >>> wrote: > >> >> > > >> >> > Hi Jc, > >> >> > > >> >> > Some notes: > >> >> > <...>/MethodBind/JvmtiTest/JvmtiTest.cpp > >> >> > and > >> >> > <...>/StackTrace/JvmtiTest/JvmtiTest.cpp > >> >> > have several places with extra space before comma > >> like: > >> >> > - ret = > >> >> JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti, > >> >> > thr), 0, max_count , stack_buffer, &count); > >> >> > + ret = jvmti->GetStackTrace(thr, 0, max_count , > >> >> stack_buffer, > >> >> > &count); > >> >> > > >> >> > <...>/functions/rawmonitor/rawmonitor.cpp > >> >> > and > >> >> > <...>/timers/JvmtiTest/JvmtiTest.cpp > >> >> > have several suspicious changes when JVMTI_ENV_PTR > and > >> >> JVMTI_ENV_ARG > >> >> > have different arguments (that's certainly wrong, but > >> needs > >> >> to re > >> >> > resolved correctly): > >> >> > - res = > >> >> > > >> >> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env, > >> >> > &main_thread)); > >> >> > + res = jvmti->GetCurrentThread(&main_thread); > >> >> > > >> >> > JVMTI_ENV_PTR(jvmti) is an address of the function > >> in the > >> >> vtable, and > >> >> > JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" > pointer. > >> >> > So I'd expect that this should be > >> >> > + res = + > >> jvmti_env->GetCurrentThread(&main_thread); > >> >> > > >> >> > Looking at timers/JvmtiTest/JvmtiTest.cpp history > >> looks like > >> >> > > >> JVMTI_ENV_PTR(jvmti)->(JVMTI_ENV_ARG(jvmti_env, ... > >> >> changes were > >> >> > introduced recently by the fix for "8209611: use C++ > >> >> compiler for > >> >> > hotspot tests". > >> >> > > >> >> > /functions/rawmonitor/rawmonitor.cpp had such wrong > >> >> statements before, > >> >> > so they should be revised carefully. > >> >> > AFAIU if JVMTI dunction is called from some callback > >> where > >> >> jvmtiEnv is > >> >> > passed, the passed value should be used. > >> >> > > >> >> > --alex > >> >> > > >> >> > On 09/13/2018 13:26, JC Beyler wrote: > >> >> > > Hi all, > >> >> > > > >> >> > > We have arrived to the last webrev for removing > >> the JNI_ENV > >> >> > macros from > >> >> > > the vmTestbase: > >> >> > > > >> >> > > Webrev: > >> >> http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/ > >> > >> >> > >> >> > > >> > >> >> > > > >> > >> >> > > Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8210700 > >> >> > > > >> >> > > Thanks again for the reviews, > >> >> > > Jc > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > > >> >> > Thanks, > >> >> > Jc > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> Thanks, > >> >> Jc > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Sep 18 03:59:43 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 17 Sep 2018 20:59:43 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp Message-ID: Hi all, I've slowly started working on JDK-8191519 . However before starting to really refactor all the tests, I thought I'd get a few opinions. I am working on internalizing the error handling of JNI calls via a SafeJNIEnv class that redefines all the JNI calls to add an error checker. The advantage is that the test code will look and feel like normal JNI code and calls but will have the checks we want to have for our tests. If agreed with this, we can augment the SafeJNIEnv class as needed. Also, if the tests require something else than fatal errors, we can add a different marker and make it a parameter to the base class. Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Sep 18 04:48:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 14:48:02 +1000 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: Message-ID: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> Hi Jc, On 18/09/2018 1:59 PM, JC Beyler wrote: > Hi all, > > I've slowly started working on JDK-8191519 > . However before > starting to really refactor all the tests, I thought I'd get a few > opinions.?I am working on internalizing the error handling of JNI calls > via a SafeJNIEnv class that redefines all the JNI calls to add an error > checker. > > The advantage is that the test code will look and feel like normal JNI > code and calls but will have the checks we want to have for our tests. Not sure I get that. Normal JNI code has to check for errors/exceptions after every call. The tests need those checks too. Today they are explicit, with this change they become implicit. Not sure what we are gaining here ?? > If agreed with this, we can augment the SafeJNIEnv class as needed. > Also, if the tests require something else than fatal errors, we can add > a different marker and make it a parameter to the base class. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > Let me know what you think, Two initial suggestions: 1. FatalOnException should be constructed with a description string so that it can report the failing operation when calling FatalError rather than the general "Problem with a JNI call". 2. Make the local SafeJNIEnv a pointer called env so that the change is less disruptive. All the env->op() calls will remain and only the local error checking will be removed. The switch from, e.g., checking NULL returns to checking for pending exceptions, need to be sure that the JNI operations clearly specify that NULL implies there will be an exception pending. This change may be an issue for static code analysis if not smart enough to understand the RAII wrappers. Thanks, David > Jc From jini.george at oracle.com Tue Sep 18 11:52:02 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 18 Sep 2018 17:22:02 +0530 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Message-ID: Hi all, Please review the small change for fixing the build failure in src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with -Werror=unused-result. https://bugs.openjdk.java.net/browse/JDK-8210836 Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ A quick review would be appreciated. Thank you! Jini. From thomas.stuefe at gmail.com Tue Sep 18 13:06:19 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Sep 2018 15:06:19 +0200 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: References: Message-ID: Looks good. Thanks for fixing. ..Thomas On Tue, Sep 18, 2018 at 1:52 PM, Jini George wrote: > Hi all, > > Please review the small change for fixing the build failure in > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with > -Werror=unused-result. > > https://bugs.openjdk.java.net/browse/JDK-8210836 > Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ > > A quick review would be appreciated. > > Thank you! > Jini. From jcbeyler at google.com Tue Sep 18 14:16:25 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 18 Sep 2018 07:16:25 -0700 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: References: Message-ID: Hi Jini, I was looking at the man page and am curious: it says that the method returns 0 if the end-of-file is reached, does that never happen in this case? (seems like -1 is the error code and another call to pread in the file just checks for <= 0; which also is weird since 0 just means end of file). Thanks, Jc On Tue, Sep 18, 2018 at 6:06 AM Thomas St?fe wrote: > Looks good. Thanks for fixing. > > ..Thomas > > On Tue, Sep 18, 2018 at 1:52 PM, Jini George > wrote: > > Hi all, > > > > Please review the small change for fixing the build failure in > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with > > -Werror=unused-result. > > > > https://bugs.openjdk.java.net/browse/JDK-8210836 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ > > > > A quick review would be appreciated. > > > > Thank you! > > Jini. > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Sep 18 16:10:28 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 12:10:28 -0400 Subject: RFR (trivial) 8210861: Move assert to help diagnose rare RedefineStress crash Message-ID: <57b8160d-8d69-a291-ada1-0e83a4cce3be@oracle.com> Summary: assert that Method being marked on stack hasn't been missed by previous metadata walk Ran hs-tier1-7 with no failures, which is unfortunate because this assert will tell me where the Method was missed from previous walk. open webrev at http://cr.openjdk.java.net/~coleenp/8210861.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8210861 Thanks, Coleen From brent.christian at oracle.com Tue Sep 18 16:42:07 2018 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 18 Sep 2018 09:42:07 -0700 Subject: RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX In-Reply-To: References: Message-ID: <0b21704e-8f05-1142-13d4-c17959407eee@oracle.com> Any thoughts on this change? -B On 9/11/18 3:41 PM, Brent Christian wrote: > Hi, > > Please review this change to how the platform encoding is determined on > Mac when loading agents. > > Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/ > > Additional details in the bug report: > https://bugs.openjdk.java.net/browse/JDK-8072130 > > Some background: > Since JDK 8, if MacOS reports an encoding of US-ASCII, but no encoding > hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), > the JDK uses UTF-8 instead; see JDK-8011194[1].? (This allowed apps > launched via double-clicked jar to display files correctly for non-ASCII > languages). > > A similar encoding tweak was not made in the code path used for loading > agents. > > This can come into play when an agent jar includes a Boot-Class-Path > entry containing non-ASCII characters.? iconv() gets setup to convert > UTF-8 to US-ASCII[2], but will fail when encountering extended > characters in the entry, so the path in question is not added to the > bootclasspath[3].? This will likely lead to a ClassNotFoundException. > > When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a > ?Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default > ?encoding of UTF-8 (per 8011194) and creates Agent.jar with a > Boot-Class-Path that includes non-ASCII characters.? But the > Boot-Class-Path entry gets skipped when loading Agent.jar, so the > AgentSupport class can't be found. > > I propose this be fixed by adding the same UTF-8 encoding adjustment on > MacOS from 8011194 to the agent loading code path. > > An additional note: > This bug was challenging to reproduce, in large part because the 8011194 > code checks for an absent env var (getenv() == null), but not for env > vars with a blank/empty string value (getenv() == ""), so the test > environment had to be setup in a specific way (e.g. 'unset LANG' vs > 'export LANG=') to reproduce this bug.? So I'd like to update the code > to also check for empty string.? I also added a couple small > improvements to the test. > > Thanks! > > -Brent > > 1. https://bugs.openjdk.java.net/browse/JDK-8011194 > 2. > http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 > > 3. > http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873 > > From lois.foltan at oracle.com Tue Sep 18 17:07:57 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 18 Sep 2018 13:07:57 -0400 Subject: RFR (trivial) 8210861: Move assert to help diagnose rare RedefineStress crash In-Reply-To: <57b8160d-8d69-a291-ada1-0e83a4cce3be@oracle.com> References: <57b8160d-8d69-a291-ada1-0e83a4cce3be@oracle.com> Message-ID: Looks good & trivial. Lois On 9/18/2018 12:10 PM, coleen.phillimore at oracle.com wrote: > Summary: assert that Method being marked on stack hasn't been missed > by previous metadata walk > > Ran hs-tier1-7 with no failures, which is unfortunate because this > assert will tell me where the Method was missed from previous walk. > > open webrev at http://cr.openjdk.java.net/~coleenp/8210861.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210861 > > Thanks, > Coleen From thomas.stuefe at gmail.com Tue Sep 18 17:19:35 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Sep 2018 19:19:35 +0200 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: References: Message-ID: I think the abbreviated form - requiring the exact number of bytes read - is fine in this case. If you want to do it really correct, you'd have to read in a loop (since you may read fewer bytes due to IO stalls) and handle EINTR. But the code before certainly did not care, so the fix does not make it worse. Since this is an urgent buildfix I'd be fine with it in this form. I agree, pread <= 0 is questionable too. Since the following code is not prepared to deal with anything but a full read, comparing to buffer size, like in the fixed example, would be better. Cheers, Thomas On Tue, Sep 18, 2018 at 4:16 PM, JC Beyler wrote: > Hi Jini, > > I was looking at the man page and am curious: it says that the method > returns 0 if the end-of-file is reached, does that never happen in this > case? > > (seems like -1 is the error code and another call to pread in the file just > checks for <= 0; which also is weird since 0 just means end of file). > > Thanks, > Jc > > On Tue, Sep 18, 2018 at 6:06 AM Thomas St?fe > wrote: >> >> Looks good. Thanks for fixing. >> >> ..Thomas >> >> On Tue, Sep 18, 2018 at 1:52 PM, Jini George >> wrote: >> > Hi all, >> > >> > Please review the small change for fixing the build failure in >> > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with >> > -Werror=unused-result. >> > >> > https://bugs.openjdk.java.net/browse/JDK-8210836 >> > Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ >> > >> > A quick review would be appreciated. >> > >> > Thank you! >> > Jini. > > > > -- > > Thanks, > Jc From jini.george at oracle.com Tue Sep 18 17:26:03 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 18 Sep 2018 22:56:03 +0530 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: References: Message-ID: <7ea8776f-2f15-77bf-03f8-f43867f10249@oracle.com> Hi JC, Thank you for looking into this. Since we are reading the PT_INTERP segment in this case to get the path of the dynamic linker, and since p_filesz denotes the size of the segment (in this case, it would be the size of the string denoting the path of the dynamic linker), if we end up reading anything less than p_filesz, it should be an error. If pread() returns a zero denoting an EOF while we are reading in the PT_INTERP segment, I guess it would mean that we are dealing with a truncated or a possibly corrupted file. Thanks! Jini. On 9/18/2018 7:46 PM, JC Beyler wrote: > Hi Jini, > > I was looking at the man page and am curious: it says that the method > returns 0 if the end-of-file is reached, does that never happen in this > case? > > (seems like -1 is the error code and another call to pread in the file > just checks for <= 0; which also is weird since 0 just means end of file). > > Thanks, > Jc > > On Tue, Sep 18, 2018 at 6:06 AM Thomas St?fe > wrote: > > Looks good. Thanks for fixing. > > ..Thomas > > On Tue, Sep 18, 2018 at 1:52 PM, Jini George > wrote: > > Hi all, > > > > Please review the small change for fixing the build failure in > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with > > -Werror=unused-result. > > > > https://bugs.openjdk.java.net/browse/JDK-8210836 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ > > > > > A quick review would be appreciated. > > > > Thank you! > > Jini. > > > > -- > > Thanks, > Jc From jini.george at oracle.com Tue Sep 18 17:28:42 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 18 Sep 2018 22:58:42 +0530 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: References: Message-ID: <0ffc511a-6da2-0c33-566d-652c16dac6c5@oracle.com> Thanks for the review, Thomas! - Jini. On 9/18/2018 6:36 PM, Thomas St?fe wrote: > Looks good. Thanks for fixing. > > ..Thomas > > On Tue, Sep 18, 2018 at 1:52 PM, Jini George wrote: >> Hi all, >> >> Please review the small change for fixing the build failure in >> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with >> -Werror=unused-result. >> >> https://bugs.openjdk.java.net/browse/JDK-8210836 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ >> >> A quick review would be appreciated. >> >> Thank you! >> Jini. From jcbeyler at google.com Tue Sep 18 17:29:28 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 18 Sep 2018 10:29:28 -0700 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: <7ea8776f-2f15-77bf-03f8-f43867f10249@oracle.com> References: <7ea8776f-2f15-77bf-03f8-f43867f10249@oracle.com> Message-ID: I agree, thanks Jini for the clarification. And to talk about the other case of pread in the file for completeness: - The pread that tests <= 0 actually is correct: as you state it is in a loop so there are two cases: - pread returns -1 and it is a failure, we break and after the loop we check if there is any residual bytes that should be read, if so we fail - pread returns 0 because it is the end was found (the len provided is a min of what is remaining and the map_info size) So its test <=0 is the right thing to do. - In the case of the code you changed, you are right; looking at the ELF format, the section header table is at the end of the file, so you can't have a segment that is at the end; hence it can never have a return 0 (or it would be an error as you stated). Thanks for taking the time to look and explain it to me :), Looks good to me (not a reviewer though), Jc On Tue, Sep 18, 2018 at 10:26 AM Jini George wrote: > Hi JC, > > Thank you for looking into this. Since we are reading the PT_INTERP > segment in this case to get the path of the dynamic linker, and since > p_filesz denotes the size of the segment (in this case, it would be the > size of the string denoting the path of the dynamic linker), if we end > up reading anything less than p_filesz, it should be an error. If > pread() returns a zero denoting an EOF while we are reading in the > PT_INTERP segment, I guess it would mean that we are dealing with a > truncated or a possibly corrupted file. > > Thanks! > Jini. > > > On 9/18/2018 7:46 PM, JC Beyler wrote: > > Hi Jini, > > > > I was looking at the man page and am curious: it says that the method > > returns 0 if the end-of-file is reached, does that never happen in this > > case? > > > > (seems like -1 is the error code and another call to pread in the file > > just checks for <= 0; which also is weird since 0 just means end of > file). > > > > Thanks, > > Jc > > > > On Tue, Sep 18, 2018 at 6:06 AM Thomas St?fe > > wrote: > > > > Looks good. Thanks for fixing. > > > > ..Thomas > > > > On Tue, Sep 18, 2018 at 1:52 PM, Jini George > > wrote: > > > Hi all, > > > > > > Please review the small change for fixing the build failure in > > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with > > > -Werror=unused-result. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8210836 > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ > > > > > > > > A quick review would be appreciated. > > > > > > Thank you! > > > Jini. > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Sep 18 17:54:24 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 18 Sep 2018 23:24:24 +0530 Subject: RFR: JDK-8210836 : Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c In-Reply-To: References: <7ea8776f-2f15-77bf-03f8-f43867f10249@oracle.com> Message-ID: <7ddf6222-a406-ab7e-efac-8c277efae616@oracle.com> Thank you, JC and Thomas! I have pushed the change. - Jini. On 9/18/2018 10:59 PM, JC Beyler wrote: > I agree, thanks Jini for the clarification. And to talk about the other > case of pread in the file for completeness: > > - The pread that tests <= 0 actually is correct: as you state it is in a > loop so there are two cases: > ? ? ?- pread returns -1 and it is a failure, we break and after the > loop we check if there is any residual bytes that should be read, if so > we fail > ? ? ?- pread returns 0 because it is the end was found (the len > provided is a min of what is remaining and the map_info size) > > So its test <=0 is the right thing to do. > > - In the case of the code you changed, you are right; looking at the ELF > format, the section header table is at the end of the file, so you can't > have a segment that is at the end; hence it can never have a return 0 > (or it would be an error as you stated). > > Thanks for taking the time to look and explain it to me :), > > Looks good to me (not a reviewer though), > Jc > > > On Tue, Sep 18, 2018 at 10:26 AM Jini George > wrote: > > Hi JC, > > Thank you for looking into this. Since we are reading the PT_INTERP > segment in this case to get the path of the dynamic linker, and since > p_filesz denotes the size of the segment (in this case, it would be the > size of the string denoting the path of the dynamic linker), if we end > up reading anything less than p_filesz, it should be an error. If > pread() returns a zero denoting an EOF while we are reading in the > PT_INTERP segment, I guess it would mean that we are dealing with a > truncated or a possibly corrupted file. > > Thanks! > Jini. > > > On 9/18/2018 7:46 PM, JC Beyler wrote: > > Hi Jini, > > > > I was looking at the man page and am curious: it says that the > method > > returns 0 if the end-of-file is reached, does that never happen > in this > > case? > > > > (seems like -1 is the error code and another call to pread in the > file > > just checks for <= 0; which also is weird since 0 just means end > of file). > > > > Thanks, > > Jc > > > > On Tue, Sep 18, 2018 at 6:06 AM Thomas St?fe > > > >> wrote: > > > >? ? ?Looks good. Thanks for fixing. > > > >? ? ?..Thomas > > > >? ? ?On Tue, Sep 18, 2018 at 1:52 PM, Jini George > > >? ? ? >> wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > Please review the small change for fixing the build failure in > >? ? ? > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with > >? ? ? > -Werror=unused-result. > >? ? ? > > >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8210836 > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jgeorge/8210836/webrev.00/ > > >? ? ? > >? ? ? > > >? ? ? > A quick review would be appreciated. > >? ? ? > > >? ? ? > Thank you! > >? ? ? > Jini. > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From jcbeyler at google.com Tue Sep 18 18:07:16 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 18 Sep 2018 11:07:16 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> Message-ID: Hi David, Thanks for the quick review and thoughts. I have now a new version here that addresses your comments: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 I've also inlined my answers/comments. > > > I've slowly started working on JDK-8191519 > > . However before > > starting to really refactor all the tests, I thought I'd get a few > > opinions. I am working on internalizing the error handling of JNI calls > > via a SafeJNIEnv class that redefines all the JNI calls to add an error > > checker. > > > > The advantage is that the test code will look and feel like normal JNI > > code and calls but will have the checks we want to have for our tests. > > Not sure I get that. Normal JNI code has to check for errors/exceptions > after every call. The tests need those checks too. Today they are > explicit, with this change they become implicit. Not sure what we are > gaining here ?? > In my humble opinion, having the error checking out of the way allows the code reader to concentrate on the JNI code while maintaining error checking. We use something similar internally, so perhaps I'm biased to it :-). If this is not a desired/helpful "feature" to simplify tests in general, I will backtrack it and just add the explicit tests to the native code of the locks for the fix https://bugs.openjdk.java.net/browse/JDK-8191519 instead. Let me however try to make my case and let me know what you all think! > > If agreed with this, we can augment the SafeJNIEnv class as needed. > > Also, if the tests require something else than fatal errors, we can add > > a different marker and make it a parameter to the base class. > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > Let me know what you think, > > Two initial suggestions: > > 1. FatalOnException should be constructed with a description string so > that it can report the failing operation when calling FatalError rather > than the general "Problem with a JNI call". > Agreed with you, the new webrev produces: FATAL ERROR in native method: GetObjectClass at nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native Method) at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) at nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) at java.lang.Thread.run(java.base at 12-internal/Thread.java:834) and for a return NULL in NewGlobalRef, we would get automatically: FATAL ERROR in native method: NewGlobalRef:Return is NULL at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native Method) at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) Again as we port and simplify more tests (I'll only do the locks for now and we can figure out the next steps as start working on moving tests out of vmTestbase), we can add, if needed, other exception handlers that don't throw or do other things depending on the JNI method outputs. > 2. Make the local SafeJNIEnv a pointer called env so that the change is > less disruptive. All the env->op() calls will remain and only the local > error checking will be removed. > Done, I used a unique_ptr to make the object created/destroyed/available as a pointer do-able in one line: std::unique_ptr env(new SafeJNIEnv(jni_env)); and then you can see that, as you mentioned, the disruption to the code is much less: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html Basically the tests now become internal to the SafeJNIEnv and the code now only contains the JNI calls happening but we are protected and will fail any test that has an exception or a NULL return for the call. Of course, this is not 100% proof in terms of not having any error handling in the test but in some cases like this, the new code seems to just work better: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > The switch from, e.g., checking NULL returns to checking for pending > exceptions, need to be sure that the JNI operations clearly specify that > NULL implies there will be an exception pending. This change may be an > issue for static code analysis if not smart enough to understand the > RAII wrappers. > Agreed, I fixed it to be more strict and say: in normal test handling, the JNI calls should never return NULL or throw an exception. This should hold for tests I imagine but if not we can add a different call verifier as we go. > > Thanks, > David > > > Jc > Let me know what you all think. When talking about it a bit, I had gotten some interest to see what it would look like. Here it is :-). Now if it is not wanted like I said, I can backtrack and just put the error checks after each JNI call for all the tests as we are porting them. Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Sep 18 19:07:46 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 18 Sep 2018 12:07:46 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals Message-ID: Hi all, Could I have a review for this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Sep 18 20:01:52 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 16:01:52 -0400 Subject: RFR (trivial) 8210861: Move assert to help diagnose rare RedefineStress crash In-Reply-To: References: <57b8160d-8d69-a291-ada1-0e83a4cce3be@oracle.com> Message-ID: <5d31de11-942f-0836-79cf-7fd4a519d099@oracle.com> Thanks, Lois! Coleen On 9/18/18 1:07 PM, Lois Foltan wrote: > Looks good & trivial. > Lois > > On 9/18/2018 12:10 PM, coleen.phillimore at oracle.com wrote: >> Summary: assert that Method being marked on stack hasn't been missed >> by previous metadata walk >> >> Ran hs-tier1-7 with no failures, which is unfortunate because this >> assert will tell me where the Method was missed from previous walk. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210861.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210861 >> >> Thanks, >> Coleen > From serguei.spitsyn at oracle.com Tue Sep 18 20:04:02 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 18 Sep 2018 13:04:02 -0700 Subject: RFR (trivial) 8210861: Move assert to help diagnose rare RedefineStress crash In-Reply-To: References: <57b8160d-8d69-a291-ada1-0e83a4cce3be@oracle.com> Message-ID: +1 Thanks, Serguei On 9/18/18 10:07 AM, Lois Foltan wrote: > Looks good & trivial. > Lois > > On 9/18/2018 12:10 PM, coleen.phillimore at oracle.com wrote: >> Summary: assert that Method being marked on stack hasn't been missed >> by previous metadata walk >> >> Ran hs-tier1-7 with no failures, which is unfortunate because this >> assert will tell me where the Method was missed from previous walk. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210861.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210861 >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Tue Sep 18 20:43:23 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 16:43:23 -0400 Subject: RFR (trivial) 8210861: Move assert to help diagnose rare RedefineStress crash In-Reply-To: References: <57b8160d-8d69-a291-ada1-0e83a4cce3be@oracle.com> Message-ID: <88b4d6ef-6e8a-ee0c-593d-839d0d9d9e6e@oracle.com> Thanks Serguei! Coleen On 9/18/18 4:04 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Thanks, > Serguei > > On 9/18/18 10:07 AM, Lois Foltan wrote: >> Looks good & trivial. >> Lois >> >> On 9/18/2018 12:10 PM, coleen.phillimore at oracle.com wrote: >>> Summary: assert that Method being marked on stack hasn't been missed >>> by previous metadata walk >>> >>> Ran hs-tier1-7 with no failures, which is unfortunate because this >>> assert will tell me where the Method was missed from previous walk. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8210861.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8210861 >>> >>> Thanks, >>> Coleen >> > From matthias.baesken at sap.com Wed Sep 19 09:12:42 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Sep 2018 09:12:42 +0000 Subject: OOM counters Message-ID: Hello, Currently we have already counters in the Hotspot codebase counting Java heap, Metaspace and class metaspace related OOMs. See declarations: jdk/src/hotspot/share/utilities/exceptions.hpp 107 // Count out of memory errors that are interesting in error diagnosis 108 static volatile int _out_of_memory_error_java_heap_errors; 109 static volatile int _out_of_memory_error_metaspace_errors; 110 static volatile int _out_of_memory_error_class_metaspace_errors; output : jdk/src/hotspot/share/utilities/exceptions.cpp 460void Exceptions::print_exception_counts_on_error(outputStream* st) { 461 print_oom_count(st, "java_heap_errors", _out_of_memory_error_java_heap_errors); 462 print_oom_count(st, "metaspace_errors", _out_of_memory_error_metaspace_errors); 463 print_oom_count(st, "class_metaspace_errors", _out_of_memory_error_class_metaspace_errors); 464 if (_stack_overflow_errors > 0) { 465 st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); 466 } 467 if (_linkage_errors > 0) { 468 st->print_cr("LinkageErrors=%d", _linkage_errors); 469 } 470} But currently the output is only done from vmError.cpp , in case of a) error reporting b) jcmd vm.info (in case exceptions happened, otherwise the section is not printed) (see void VMError::print_vm_info(outputStream* st) { ... } ) It would be interesting for us to get the values of the existing counters via JDK coding. In our proprietary JVM we had a similar mechanism. Is there anything planned for this (or even already something present) ? There exists already a class java/lang/management/MemoryMXBean.java with a management interface for the memory system of the Java virtual machine. It contains some "getter" - methods like public int getObjectPendingFinalizationCount(); public MemoryUsage getHeapMemoryUsage(); Do you think we could add a method (or methods) for accessing the existing OOM counters ( for example, public OomCounters getOutOfMemoryCounters(); ) ? Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Sep 19 16:01:03 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Sep 2018 16:01:03 +0000 Subject: OOM counters In-Reply-To: References: Message-ID: Hi JC, yes it is good to have for monitoring. However another application we have is that people wanted to trigger actions on an OOM occurrence , like doing some restarts etc . For these kind of actions they had in our proprietary JVM some kind of queue containing the latest ?prominent? errors (OOMs , but also some others). So they periodically checked the queue and in case an OOM is found , they started the desired action . There is (to some extend) a replacement for this in the VM, the XX flags ExitOnOutOfMemoryError and OnOutOfMemoryError= . However, these flags are not very flexible (always exiting is not what all people want), and executing a command forks and execs a shell (see vmError) which is quite some overhead and also a bit problematic in some cases. Best regards, Matthias From: JC Beyler Sent: Mittwoch, 19. September 2018 16:49 To: Baesken, Matthias Cc: hotspot-dev Source Developers ; serviceability-dev at openjdk.java.net Subject: Re: OOM counters Hi Matthias, In the case of an OOM, what's the use-case here? Are there cases where you are recuperating often from OOMs that the counters have different values and it's interesting to monitor? Or is it to determine which of the three got incremented by the OOM that was thrown? Finally, when would you call the MemoryMXBean new call: if you are recuperating from OOMs, I could imagine that you might be able to get the counters periodically and monitor this; if you're not, you'd be doing this call during an OOM? Thanks, Jc On Wed, Sep 19, 2018 at 2:13 AM Baesken, Matthias > wrote: Hello, Currently we have already counters in the Hotspot codebase counting Java heap, Metaspace and class metaspace related OOMs. See declarations: jdk/src/hotspot/share/utilities/exceptions.hpp 107 // Count out of memory errors that are interesting in error diagnosis 108 static volatile int _out_of_memory_error_java_heap_errors; 109 static volatile int _out_of_memory_error_metaspace_errors; 110 static volatile int _out_of_memory_error_class_metaspace_errors; output : jdk/src/hotspot/share/utilities/exceptions.cpp 460void Exceptions::print_exception_counts_on_error(outputStream* st) { 461 print_oom_count(st, "java_heap_errors", _out_of_memory_error_java_heap_errors); 462 print_oom_count(st, "metaspace_errors", _out_of_memory_error_metaspace_errors); 463 print_oom_count(st, "class_metaspace_errors", _out_of_memory_error_class_metaspace_errors); 464 if (_stack_overflow_errors > 0) { 465 st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); 466 } 467 if (_linkage_errors > 0) { 468 st->print_cr("LinkageErrors=%d", _linkage_errors); 469 } 470} But currently the output is only done from vmError.cpp , in case of a) error reporting b) jcmd vm.info (in case exceptions happened, otherwise the section is not printed) (see void VMError::print_vm_info(outputStream* st) { ... } ) It would be interesting for us to get the values of the existing counters via JDK coding. In our proprietary JVM we had a similar mechanism. Is there anything planned for this (or even already something present) ? There exists already a class java/lang/management/MemoryMXBean.java with a management interface for the memory system of the Java virtual machine. It contains some "getter" - methods like public int getObjectPendingFinalizationCount(); public MemoryUsage getHeapMemoryUsage(); Do you think we could add a method (or methods) for accessing the existing OOM counters ( for example, public OomCounters getOutOfMemoryCounters(); ) ? Best regards, Matthias -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Sep 19 21:30:40 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 19 Sep 2018 14:30:40 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> Message-ID: Hi Jc, Updated tests looks good. Some notes about implementation. - FatalOnException implements both verification and error handling It would be better to separate them (and this makes easy to implement error handling different from JNIEnv::FatalError). The simplest way is to define error handler as class SafeJNIEnv { public: typedef void (*ErrorHandler)(JNIEnv *env, const char* errorMsg); // error handler which terminates jvm by using FatalError() static void FatalError(JNIEnv *env, const char *errrorMsg); SafeJNIEnv(JNIEnv* jni_env, ErrorHandler errorHandler = FatalError); (SafeJNIEnv methods should create FatalOnException objects passing errorHandler) - FatalOnException is used in SafeJNIEnv methods as FatalOnException marker(this, "msg"); ret = (optional)marker.check_for_null(ret); return ret; But actually I'd call it something like JNICallResultVerifier and create the object after JNI call. like ret = JNICallResultVerifier(this, "msg") (optional).notNull(ret); return ret; or even (if you like such syntax sugar) you can define template T resultNotNull(T result) { notNull(result); return result; } and do ret = return JNICallResultVerifier(this, "msg").resultNotNull(ret); - you added #include in the test (and you have to add it to every test). It would be simpler to add the include to SafeJNIEnv.hpp and define typedef std::unique_ptr SafeJNIEnvPtr; Then each in the test methods: SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); or you can add static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, ErrorHandler errorHandler = fatalError) and get SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); - it would be better to wrap internal classes (FatalOnException) into unnamed namespace - this helps to avoid conflicts with other classes) - FatalOnException::check_for_null(void* ptr) should be FatalOnException::check_for_null(const void* ptr) And calling the method you don't need reinterpret_cast --alex On 09/18/2018 11:07, JC Beyler wrote: > Hi David, > > Thanks for the quick review and thoughts. I have now a new version here > that addresses your comments: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > I've also inlined my answers/comments. > > > > > I've slowly started working on JDK-8191519 > > . However before > > starting to really refactor all the tests, I thought I'd get a few > > opinions.?I am working on internalizing the error handling of JNI > calls > > via a SafeJNIEnv class that redefines all the JNI calls to add an > error > > checker. > > > > The advantage is that the test code will look and feel like > normal JNI > > code and calls but will have the checks we want to have for our > tests. > > Not sure I get that. Normal JNI code has to check for errors/exceptions > after every call. The tests need those checks too. Today they are > explicit, with this change they become implicit. Not sure what we are > gaining here ?? > > > In my humble opinion, having the error checking out of the way allows > the code reader to concentrate on the JNI code while maintaining error > checking. We use something similar internally, so perhaps I'm biased to > it :-). > If this is not a desired/helpful "feature" to simplify tests in general, > I will backtrack it and just add the explicit tests to the native code > of the locks for the fix > https://bugs.openjdk.java.net/browse/JDK-8191519?instead. > > Let me however try to make my case and let me know what you all think! > > > > If agreed with this, we can augment the SafeJNIEnv class as needed. > > Also, if the tests require something else than fatal errors, we > can add > > a different marker and make it a parameter to the base class. > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > Let me know what you think, > > Two initial suggestions: > > 1. FatalOnException should be constructed with a description string so > that it can report the failing operation when calling FatalError rather > than the general "Problem with a JNI call". > > > Agreed with you, the new webrev produces: > > FATAL ERROR in native method: GetObjectClass > at nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native Method) > at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > at nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > at java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > and for a return NULL in NewGlobalRef, we would get automatically: > > FATAL ERROR in native method: NewGlobalRef:Return is NULL > at nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native Method) > > ? ? ? ? at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > Again as we port and simplify more tests (I'll only do the locks for now > and we can figure out the next steps as start working on moving tests > out of vmTestbase), > we can add, if needed, other exception handlers that don't throw or do > other things depending on the JNI method outputs. > > > 2. Make the local SafeJNIEnv a pointer called env so that the change is > less disruptive. All the env->op() calls will remain and only the local > error checking will be removed. > > > Done, I used a unique_ptr to make the object created/destroyed/available > as a pointer do-able in one line: > std::unique_ptr env(new SafeJNIEnv(jni_env)); > > and then you can see that, as you mentioned, the disruption to the code > is much less: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > Basically the tests now become internal to the SafeJNIEnv and the code > now only contains the JNI calls happening but we are protected and will > fail any test that has an exception or a NULL return for the call. Of > course, this is not 100% proof in terms of not having any error handling > in the test but in some cases like this, the new code seems to just work > better: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > The switch from, e.g., checking NULL returns to checking for pending > exceptions, need to be sure that the JNI operations clearly specify > that > NULL implies there will be an exception pending. This change may be an > issue for static code analysis if not smart enough to understand the > RAII wrappers. > > > Agreed, I fixed it to be more strict and say: in normal test handling, > the JNI calls should never return NULL or throw an exception. This > should hold for tests I imagine but if not we can add a different call > verifier as we go. > > > Thanks, > David > > > Jc > > > > Let me know what you all think. When talking about it a bit, I had > gotten some interest to see what it would look like. Here it is :-). Now > if it is not wanted like I said, I can backtrack and just put the error > checks after each JNI call for all the tests as we are porting them. > Jc From jcbeyler at google.com Wed Sep 19 22:56:47 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 19 Sep 2018 15:56:47 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> Message-ID: Hi Alex, I've updated the webrev to: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 That webrev has the code that is shown here in snippets. Thanks for the reviews, I've relatively followed your reviews except for one detail due to me wanting to handle the NSK_JNI_VERIFY macros via this system as well later down the road. For an example: We currently have in the code: if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = NSK_CPP_STUB2(GetObjectClass, pEnv, mhToCall)) != NULL) ) 1) The NSK_CPP_STUB2 is trivially removed with a refactor (JDK-8210728) to: if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) != NULL) ) 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it becomes via this wrapping of JNIEnv: if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) 3) Then, via removing the assignment, we'd arrive to a: mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); if (!mhClass) Without any loss of checking for failures, etc. So that is my motivation for most of this work with a concrete example (hopefully it helps drive this conversation). I inlined my answers here, let me know what you think. On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov wrote: > Hi Jc, > > Updated tests looks good. > Some notes about implementation. > > - FatalOnException implements both verification and error handling > It would be better to separate them (and this makes easy to implement > error handling different from JNIEnv::FatalError). > The simplest way is to define error handler as > class SafeJNIEnv { > public: > typedef void (*ErrorHandler)(JNIEnv *env, const char* errorMsg); > // error handler which terminates jvm by using FatalError() > static void FatalError(JNIEnv *env, const char *errrorMsg); > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler errorHandler = FatalError); > (SafeJNIEnv methods should create FatalOnException objects passing > errorHandler) > Agreed, I tried to keep the code simple. The concepts you talk about here are generally what I reserve for when I need it (ie extensions and handling new cases). But a lot are going to be needed soon so I think it is a good time to iron the code out now on this "simple" webrev. So done for this. > > > - FatalOnException is used in SafeJNIEnv methods as > FatalOnException marker(this, "msg"); > ret = > (optional)marker.check_for_null(ret); > return ret; > But actually I'd call it something like JNICallResultVerifier and create > the object after JNI call. like > ret = > JNICallResultVerifier(this, "msg") > (optional).notNull(ret); > return ret; > or even (if you like such syntax sugar) you can define > template > T resultNotNull(T result) { > notNull(result); > return result; > } > and do > ret = > return JNICallResultVerifier(this, "msg").resultNotNull(ret); > So I renamed FatalOnException to now being JNIVerifier. Though I like it, I don't think we can do it, except if we do it slightly differently: I'm trying to solve two problems with one stone: - How to check for returns of JNI calls in the way that is done here - How to remove NSK_JNI_VERIFY* (from nsk/share/jni/jni_tools) However, the NSK_JNI_VERIFY need to start a tracing system before the call to JNI, so it won't work this way. (Side question would be do we still care about the tracing in NSK_JNI_VERIFY, if we don't then your solution works well in most situations). My vision or intuition is that we would throw a template at some point on SafeJNIEnv to handle both cases and have JNIVerifier become a specialization in certain cases and something different for the NSK_JNI_VERIFY case (or have a different constructor to enable tracing). But for now, I offer the implementation that does: jclass SafeJNIEnv::GetObjectClass(jobject obj) { JNIVerifier marker(this, "GetObjectClass"); return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); } and: void SafeJNIEnv::SetObjectField(jobject obj, jfieldID field, jobject value) { JNIVerifier<> marker(this, "SetObjectField"); _jni_env->SetObjectField(obj, field, value); } > > > - you added #include in the test (and you have to add it to > every test). > It would be simpler to add the include to SafeJNIEnv.hpp and define > typedef std::unique_ptr SafeJNIEnvPtr; > Then each in the test methods: > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > or you can add > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, ErrorHandler > errorHandler = fatalError) > and get > SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > Done, I like that, even less code change to tests then. > > > - it would be better to wrap internal classes (FatalOnException) into > unnamed namespace - this helps to avoid conflicts with other classes) > > - FatalOnException::check_for_null(void* ptr) > should be > FatalOnException::check_for_null(const void* ptr) > And calling the method you don't need reinterpret_cast > Also done, it got renamed to ResultNotNull, is using a template now, but agreed, that worked. Thanks again for the review, Jc > --alex > > > On 09/18/2018 11:07, JC Beyler wrote: > > Hi David, > > > > Thanks for the quick review and thoughts. I have now a new version here > > that addresses your comments: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > I've also inlined my answers/comments. > > > > > > > > > I've slowly started working on JDK-8191519 > > > . However > before > > > starting to really refactor all the tests, I thought I'd get a few > > > opinions. I am working on internalizing the error handling of JNI > > calls > > > via a SafeJNIEnv class that redefines all the JNI calls to add an > > error > > > checker. > > > > > > The advantage is that the test code will look and feel like > > normal JNI > > > code and calls but will have the checks we want to have for our > > tests. > > > > Not sure I get that. Normal JNI code has to check for > errors/exceptions > > after every call. The tests need those checks too. Today they are > > explicit, with this change they become implicit. Not sure what we are > > gaining here ?? > > > > > > In my humble opinion, having the error checking out of the way allows > > the code reader to concentrate on the JNI code while maintaining error > > checking. We use something similar internally, so perhaps I'm biased to > > it :-). > > If this is not a desired/helpful "feature" to simplify tests in general, > > I will backtrack it and just add the explicit tests to the native code > > of the locks for the fix > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > Let me however try to make my case and let me know what you all think! > > > > > > > If agreed with this, we can augment the SafeJNIEnv class as > needed. > > > Also, if the tests require something else than fatal errors, we > > can add > > > a different marker and make it a parameter to the base class. > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > Let me know what you think, > > > > Two initial suggestions: > > > > 1. FatalOnException should be constructed with a description string > so > > that it can report the failing operation when calling FatalError > rather > > than the general "Problem with a JNI call". > > > > > > Agreed with you, the new webrev produces: > > > > FATAL ERROR in native method: GetObjectClass > > at > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native Method) > > at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > at > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > at java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > and for a return NULL in NewGlobalRef, we would get automatically: > > > > FATAL ERROR in native method: NewGlobalRef:Return is NULL > > at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native Method) > > > > at > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > Again as we port and simplify more tests (I'll only do the locks for now > > and we can figure out the next steps as start working on moving tests > > out of vmTestbase), > > we can add, if needed, other exception handlers that don't throw or do > > other things depending on the JNI method outputs. > > > > > > 2. Make the local SafeJNIEnv a pointer called env so that the change > is > > less disruptive. All the env->op() calls will remain and only the > local > > error checking will be removed. > > > > > > Done, I used a unique_ptr to make the object created/destroyed/available > > as a pointer do-able in one line: > > std::unique_ptr env(new SafeJNIEnv(jni_env)); > > > > and then you can see that, as you mentioned, the disruption to the code > > is much less: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > Basically the tests now become internal to the SafeJNIEnv and the code > > now only contains the JNI calls happening but we are protected and will > > fail any test that has an exception or a NULL return for the call. Of > > course, this is not 100% proof in terms of not having any error handling > > in the test but in some cases like this, the new code seems to just work > > better: > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > The switch from, e.g., checking NULL returns to checking for pending > > exceptions, need to be sure that the JNI operations clearly specify > > that > > NULL implies there will be an exception pending. This change may be > an > > issue for static code analysis if not smart enough to understand the > > RAII wrappers. > > > > > > Agreed, I fixed it to be more strict and say: in normal test handling, > > the JNI calls should never return NULL or throw an exception. This > > should hold for tests I imagine but if not we can add a different call > > verifier as we go. > > > > > > Thanks, > > David > > > > > Jc > > > > > > > > Let me know what you all think. When talking about it a bit, I had > > gotten some interest to see what it would look like. Here it is :-). Now > > if it is not wanted like I said, I can backtrack and just put the error > > checks after each JNI call for all the tests as we are porting them. > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Thu Sep 20 00:13:43 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 19 Sep 2018 17:13:43 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> Message-ID: <48a98692-fa59-d445-de36-434220618e98@oracle.com> Hi Jc, Looks good to me. A minor note: - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid global namespece pollution (ErrorHandler is too generic name). --alex On 09/19/2018 15:56, JC Beyler wrote: > Hi Alex, > > I've updated the webrev to: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > That webrev has the code that is shown here in snippets. > > > Thanks for the reviews, I've relatively followed your reviews except for > one detail due to me wanting to handle the NSK_JNI_VERIFY macros via > this system as well later down the road. For an example: > > We currently have in the code: > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = NSK_CPP_STUB2(GetObjectClass, > pEnv, mhToCall)) != NULL) ) > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor (JDK-8210728) > ?to: > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = pEnv->GetObjectClass(pEnv, > mhToCall)) != NULL) ) > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it becomes via > this wrapping of JNIEnv: > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > > 3) Then, via removing the assignment, we'd arrive to a: > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > if (!mhClass) > > Without any loss of checking for failures, etc. > > So that is my motivation for most of this work with a concrete example > (hopefully it helps drive this conversation). > > I inlined my answers here, let me know?what you think. > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > wrote: > > Hi Jc, > > Updated tests looks good. > Some notes about implementation. > > - FatalOnException implements both verification and error handling > It would be better to separate them (and this makes easy to implement > error handling different from JNIEnv::FatalError). > The simplest way is to define error handler as > class SafeJNIEnv { > public: > ? ? ?typedef void (*ErrorHandler)(JNIEnv *env, const char* errorMsg); > ? ? ?// error handler which terminates jvm by using FatalError() > ? ? ?static void FatalError(JNIEnv *env, const char *errrorMsg); > > ? ? ?SafeJNIEnv(JNIEnv* jni_env, ErrorHandler errorHandler = > FatalError); > (SafeJNIEnv methods should create FatalOnException objects passing > errorHandler) > > > > Agreed, I tried to keep the code simple. The concepts you talk about > here are generally what I reserve for when I need it (ie extensions and > handling new cases). But a lot are going to be needed soon so I think it > is a good time to iron the code out now on this "simple" webrev. > > So done for this. > > > > - FatalOnException is used in SafeJNIEnv methods as > ? ?FatalOnException marker(this, "msg"); > ? ?ret = > ? ?(optional)marker.check_for_null(ret); > ? ?return ret; > But actually I'd call it something like JNICallResultVerifier and > create > the object after JNI call. like > ? ?ret = > ? ?JNICallResultVerifier(this, "msg") > ? ? ?(optional).notNull(ret); > ? ?return ret; > or even (if you like such syntax sugar) you can define > ? ?template > ? ?T resultNotNull(T result) { > ? ? ? ?notNull(result); > ? ? ? ?return result; > ? ?} > and do > ? ?ret = > ? ?return JNICallResultVerifier(this, "msg").resultNotNull(ret); > > > So I renamed FatalOnException to now being JNIVerifier. > > Though I like it, I don't think we can do it, except if we do it > slightly differently: > I'm trying to solve two problems with one stone: > ? ?- How to check for returns of JNI calls in the way that is done here > ? ?- How to remove NSK_JNI_VERIFY* (from nsk/share/jni/jni_tools) > > However, the NSK_JNI_VERIFY need to start a tracing system before the > call to JNI, so it won't work this way. (Side question would be do we > still care about the tracing in NSK_JNI_VERIFY, if we don't then your > solution works well in most situations). > > My vision or intuition is that we would throw a template at some point > on SafeJNIEnv to handle both cases and have JNIVerifier become a > specialization in certain cases and something different for the > NSK_JNI_VERIFY case (or have a different constructor to enable tracing). > But for now, I offer the implementation that does: > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > ? JNIVerifier marker(this, "GetObjectClass"); > ? return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > } > > and: > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID field, jobject > value) { > ? JNIVerifier<> marker(this, "SetObjectField"); > ? _jni_env->SetObjectField(obj, field, value); > } > > > > > - you added #include in the test (and you have to add it to > every test). > It would be simpler to add the include to SafeJNIEnv.hpp and define > typedef std::unique_ptr SafeJNIEnvPtr; > Then each in the test methods: > ? ?SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > or you can add > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, ErrorHandler > errorHandler = fatalError) > and get > ? ?SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > > > Done, I like that, even less code change to tests then. > > > > - it would be better to wrap internal classes (FatalOnException) into > unnamed namespace - this helps to avoid conflicts with other classes) > > - FatalOnException::check_for_null(void* ptr) > should be > FatalOnException::check_for_null(const void* ptr) > And calling the method you don't need reinterpret_cast > > > Also done, it got renamed to ResultNotNull, is using a template now, but > agreed, that worked. > Thanks again for the review, > Jc > > > --alex > > > On 09/18/2018 11:07, JC Beyler wrote: > > Hi David, > > > > Thanks for the quick review and thoughts. I have now a new > version here > > that addresses your comments: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > I've also inlined my answers/comments. > > > > > > > >? ? ? > I've slowly started working on JDK-8191519 > >? ? ? > . > However before > >? ? ? > starting to really refactor all the tests, I thought I'd > get a few > >? ? ? > opinions.?I am working on internalizing the error handling > of JNI > >? ? ?calls > >? ? ? > via a SafeJNIEnv class that redefines all the JNI calls to > add an > >? ? ?error > >? ? ? > checker. > >? ? ? > > >? ? ? > The advantage is that the test code will look and feel like > >? ? ?normal JNI > >? ? ? > code and calls but will have the checks we want to have > for our > >? ? ?tests. > > > >? ? ?Not sure I get that. Normal JNI code has to check for > errors/exceptions > >? ? ?after every call. The tests need those checks too. Today they are > >? ? ?explicit, with this change they become implicit. Not sure > what we are > >? ? ?gaining here ?? > > > > > > In my humble opinion, having the error checking out of the way > allows > > the code reader to concentrate on the JNI code while maintaining > error > > checking. We use something similar internally, so perhaps I'm > biased to > > it :-). > > If this is not a desired/helpful "feature" to simplify tests in > general, > > I will backtrack it and just add the explicit tests to the native > code > > of the locks for the fix > > https://bugs.openjdk.java.net/browse/JDK-8191519?instead. > > > > Let me however try to make my case and let me know what you all > think! > > > > > >? ? ? > If agreed with this, we can augment the SafeJNIEnv class > as needed. > >? ? ? > Also, if the tests require something else than fatal > errors, we > >? ? ?can add > >? ? ? > a different marker and make it a parameter to the base class. > >? ? ? > > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > >? ? ? > >? ? ? > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? > > >? ? ? > Let me know what you think, > > > >? ? ?Two initial suggestions: > > > >? ? ?1. FatalOnException should be constructed with a description > string so > >? ? ?that it can report the failing operation when calling > FatalError rather > >? ? ?than the general "Problem with a JNI call". > > > > > > Agreed with you, the new webrev produces: > > > > FATAL ERROR in native method: GetObjectClass > >? ? ? ? ? at > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > >? ? ? ? ? at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > Method) > >? ? ? ? ? at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? ? ? at > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > >? ? ? ? ? at > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > and for a return NULL in NewGlobalRef, we would get automatically: > > > > FATAL ERROR in native method: NewGlobalRef:Return is NULL > >? ? ? ? ? at > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > Method) > > > >? ? ? ? ? at > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > Again as we port and simplify more tests (I'll only do the locks > for now > > and we can figure out the next steps as start working on moving > tests > > out of vmTestbase), > > we can add, if needed, other exception handlers that don't throw > or do > > other things depending on the JNI method outputs. > > > > > >? ? ?2. Make the local SafeJNIEnv a pointer called env so that the > change is > >? ? ?less disruptive. All the env->op() calls will remain and only > the local > >? ? ?error checking will be removed. > > > > > > Done, I used a unique_ptr to make the object > created/destroyed/available > > as a pointer do-able in one line: > > std::unique_ptr env(new SafeJNIEnv(jni_env)); > > > > and then you can see that, as you mentioned, the disruption to > the code > > is much less: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > Basically the tests now become internal to the SafeJNIEnv and the > code > > now only contains the JNI calls happening but we are protected > and will > > fail any test that has an exception or a NULL return for the > call. Of > > course, this is not 100% proof in terms of not having any error > handling > > in the test but in some cases like this, the new code seems to > just work > > better: > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > >? ? ?The switch from, e.g., checking NULL returns to checking for > pending > >? ? ?exceptions, need to be sure that the JNI operations clearly > specify > >? ? ?that > >? ? ?NULL implies there will be an exception pending. This change > may be an > >? ? ?issue for static code analysis if not smart enough to > understand the > >? ? ?RAII wrappers. > > > > > > Agreed, I fixed it to be more strict and say: in normal test > handling, > > the JNI calls should never return NULL or throw an exception. This > > should hold for tests I imagine but if not we can add a different > call > > verifier as we go. > > > > > >? ? ?Thanks, > >? ? ?David > > > >? ? ? > Jc > > > > > > > > Let me know what you all think. When talking about it a bit, I had > > gotten some interest to see what it would look like. Here it is > :-). Now > > if it is not wanted like I said, I can backtrack and just put the > error > > checks after each JNI call for all the tests as we are porting them. > > Jc > > > > -- > > Thanks, > Jc From alexey.menkov at oracle.com Thu Sep 20 00:20:36 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 19 Sep 2018 17:20:36 -0700 Subject: Ping: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> <5B9FF1DC.40806@oracle.com> <5B9FF8FE.6060209@oracle.com> Message-ID: Hi all, Ping. The bug has been labeled "timewaster" as it caused failures quite often. --alex On 09/17/2018 12:57, Alex Menkov wrote: > Hi Gary, > > updated webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.02/ > > see comments inline. > > On 09/17/2018 11:57, Gary Adams wrote: >> Should sleepTime also be adjusted? > > No. > sleepTime is delay before we read jdb output (i.e. we don't read jdb > output on every update, but check for new data once a second) > >> >> Should sleepTime and timeout be scoped to >> just waitForPrompt? > > They are defined at the block where all constants are defined. > I made the constants final. > >> >> On 9/17/18, 2:26 PM, Gary Adams wrote: >>> Is the log decoration typical? >>> >>> 98???????????? jdb.log("======================================="); > > This is to make clearer the exact point error occurs. > (I initially tried just log "Exception thrown during test execution: " + > e.getMessage(), but it's too inconspicuous) > >>> >>> Is the Utils.adjustTimeout() applied consistently? >>> e.g. is the timeout passed to waitFor() already adjusted? > > waitFor timeouts are adjusted. > >>> >>> If you are promoting log() to be publicly visible, then it >>> should be used for the other cases of println() in Jdb and JdbTest. > > fixed. > > --alex > >>> >>> On 9/17/18, 1:58 PM, JC Beyler wrote: >>>> Hi Alex, >>>> >>>> Looks good to me, >>>> Jc >>>> >>>> On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov >>>> > wrote: >>>> >>>> ??? Hi all, >>>> >>>> ??? please review small fix: >>>> ??? http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ >>>> ??? >>>> >>>> ??? It fixes >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8210725 >>>> ??? - accordingly the logs of the failing tests, they work as >>>> ??? expected, but >>>> ??? sometimes (busy environment?) there is no reply from jdb for 60 >>>> ??? seconds, >>>> ??? so tests throw exception. >>>> ??? The timeout can be removed at all (so timeouts would be handled by >>>> ??? general jtreg timeout mechanism), but prefer keep smaller timeout >>>> ??? for >>>> ??? jdb reply, but apply timefactor to the value. >>>> >>>> ??? Also the change fixes >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8210748 >>>> ??? - in the case of error additional logging is done to indicate >>>> ??? certain >>>> ??? point where the error occurs. >>>> >>>> ??? --alex >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >> From david.holmes at oracle.com Thu Sep 20 01:12:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Sep 2018 11:12:38 +1000 Subject: OOM counters In-Reply-To: References: Message-ID: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> Hi Matthias, Those counters, as I recall, were added to the hs_err report purely to show if an application/test had been "playing too close to the edge" before it crashed. They were never intended as user-inspectable values. I have no opinion as to whether they should be. David On 19/09/2018 7:12 PM, Baesken, Matthias wrote: > Hello,? Currently we have already counters in the Hotspot codebase > counting Java heap, > > Metaspace and class metaspace related OOMs. > > See declarations: > > jdk/src/hotspot/share/utilities/exceptions.hpp > > 107? // Count out of memory errors that are interesting in error diagnosis > > 108? static volatile int _out_of_memory_error_java_heap_errors; > > 109? static volatile int _out_of_memory_error_metaspace_errors; > > 110? static volatile int _out_of_memory_error_class_metaspace_errors; > > output : > > jdk/src/hotspot/share/utilities/exceptions.cpp > > 460void Exceptions::print_exception_counts_on_error(outputStream* st) { > > 461? print_oom_count(st, "java_heap_errors", > _out_of_memory_error_java_heap_errors); > > 462? print_oom_count(st, "metaspace_errors", > _out_of_memory_error_metaspace_errors); > > 463? print_oom_count(st, "class_metaspace_errors", > _out_of_memory_error_class_metaspace_errors); > > 464? if (_stack_overflow_errors > 0) { > > 465??? st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); > > 466? } > > 467? if (_linkage_errors > 0) { > > 468??? st->print_cr("LinkageErrors=%d", _linkage_errors); > > 469? } > > 470} > > But currently? the output is? only done from vmError.cpp , in case of > > a)? error reporting > > b)? jcmd? vm.info? (in case exceptions happened, otherwise the section > is not printed) > > (see void VMError::print_vm_info(outputStream* st) { ... } ) > > It would be interesting for us to get the values of the existing > counters via JDK coding. > > In our proprietary JVM we had a similar mechanism. > > Is there anything planned for this (or even already something present) ? > > There exists already a class java/lang/management/MemoryMXBean.java > with a? management interface for the memory system of > > the Java virtual machine.? It contains some "getter" - methods like > > ??? public int getObjectPendingFinalizationCount(); > > ??? public MemoryUsage getHeapMemoryUsage(); > > Do you think we could add a method (or methods) for accessing the > existing OOM counters > > ( for example,? public OomCounters getOutOfMemoryCounters();? ) ? > > Best regards, Matthias > From matthias.baesken at sap.com Thu Sep 20 06:43:19 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 20 Sep 2018 06:43:19 +0000 Subject: OOM counters In-Reply-To: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> References: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> Message-ID: Hi David , the values are already user-inspectable via jcmd vm.info , however this way is not very user friendly (and I am not sure how stable it is between updates / releases). Probably not as stable as an API . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 20. September 2018 03:13 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; serviceability- > dev at openjdk.java.net serviceability-dev at openjdk.java.net dev at openjdk.java.net> > Subject: Re: OOM counters > > Hi Matthias, > > > Those counters, as I recall, were added to the hs_err report purely to > show if an application/test had been "playing too close to the edge" > before it crashed. They were never intended as user-inspectable values. > > I have no opinion as to whether they should be. > > David > > On 19/09/2018 7:12 PM, Baesken, Matthias wrote: > > Hello,? Currently we have already counters in the Hotspot codebase > > counting Java heap, > > > > Metaspace and class metaspace related OOMs. > > > > See declarations: > > > > jdk/src/hotspot/share/utilities/exceptions.hpp > > > > 107? // Count out of memory errors that are interesting in error diagnosis > > > > 108? static volatile int _out_of_memory_error_java_heap_errors; > > > > 109? static volatile int _out_of_memory_error_metaspace_errors; > > > > 110? static volatile int _out_of_memory_error_class_metaspace_errors; > > > > output : > > > > jdk/src/hotspot/share/utilities/exceptions.cpp > > > > 460void Exceptions::print_exception_counts_on_error(outputStream* st) > { > > > > 461? print_oom_count(st, "java_heap_errors", > > _out_of_memory_error_java_heap_errors); > > > > 462? print_oom_count(st, "metaspace_errors", > > _out_of_memory_error_metaspace_errors); > > > > 463? print_oom_count(st, "class_metaspace_errors", > > _out_of_memory_error_class_metaspace_errors); > > > > 464? if (_stack_overflow_errors > 0) { > > > > 465??? st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); > > > > 466? } > > > > 467? if (_linkage_errors > 0) { > > > > 468??? st->print_cr("LinkageErrors=%d", _linkage_errors); > > > > 469? } > > > > 470} > > > > But currently? the output is? only done from vmError.cpp , in case of > > > > a)? error reporting > > > > b)? jcmd? vm.info? (in case exceptions happened, otherwise the section > > is not printed) > > > > (see void VMError::print_vm_info(outputStream* st) { ... } ) > > > > It would be interesting for us to get the values of the existing > > counters via JDK coding. > > > > In our proprietary JVM we had a similar mechanism. > > > > Is there anything planned for this (or even already something present) ? > > > > There exists already a class java/lang/management/MemoryMXBean.java > > with a? management interface for the memory system of > > > > the Java virtual machine.? It contains some "getter" - methods like > > > > ??? public int getObjectPendingFinalizationCount(); > > > > ??? public MemoryUsage getHeapMemoryUsage(); > > > > Do you think we could add a method (or methods) for accessing the > > existing OOM counters > > > > ( for example,? public OomCounters getOutOfMemoryCounters();? ) ? > > > > Best regards, Matthias > > From fairoz.matte at oracle.com Thu Sep 20 13:36:58 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 20 Sep 2018 06:36:58 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core Message-ID: Hi, Kindly review the backport of "JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 JDK9 changeset - http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 JDK9 review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-October/020543.html Thanks, Fairoz From jcbeyler at google.com Thu Sep 20 15:52:33 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 20 Sep 2018 08:52:33 -0700 Subject: Ping: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> <5B9FF1DC.40806@oracle.com> <5B9FF8FE.6060209@oracle.com> Message-ID: Hi Alex, Looks good to me still :) Jc On Wed, Sep 19, 2018 at 5:21 PM Alex Menkov wrote: > Hi all, > > Ping. > The bug has been labeled "timewaster" as it caused failures quite often. > > --alex > > On 09/17/2018 12:57, Alex Menkov wrote: > > Hi Gary, > > > > updated webrev: > > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.02/ > > > > see comments inline. > > > > On 09/17/2018 11:57, Gary Adams wrote: > >> Should sleepTime also be adjusted? > > > > No. > > sleepTime is delay before we read jdb output (i.e. we don't read jdb > > output on every update, but check for new data once a second) > > > >> > >> Should sleepTime and timeout be scoped to > >> just waitForPrompt? > > > > They are defined at the block where all constants are defined. > > I made the constants final. > > > >> > >> On 9/17/18, 2:26 PM, Gary Adams wrote: > >>> Is the log decoration typical? > >>> > >>> 98 jdb.log("======================================="); > > > > This is to make clearer the exact point error occurs. > > (I initially tried just log "Exception thrown during test execution: " + > > e.getMessage(), but it's too inconspicuous) > > > >>> > >>> Is the Utils.adjustTimeout() applied consistently? > >>> e.g. is the timeout passed to waitFor() already adjusted? > > > > waitFor timeouts are adjusted. > > > >>> > >>> If you are promoting log() to be publicly visible, then it > >>> should be used for the other cases of println() in Jdb and JdbTest. > > > > fixed. > > > > --alex > > > >>> > >>> On 9/17/18, 1:58 PM, JC Beyler wrote: > >>>> Hi Alex, > >>>> > >>>> Looks good to me, > >>>> Jc > >>>> > >>>> On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov > >>>> > wrote: > >>>> > >>>> Hi all, > >>>> > >>>> please review small fix: > >>>> http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ > >>>> > > >>>> > >>>> It fixes > >>>> https://bugs.openjdk.java.net/browse/JDK-8210725 > >>>> - accordingly the logs of the failing tests, they work as > >>>> expected, but > >>>> sometimes (busy environment?) there is no reply from jdb for 60 > >>>> seconds, > >>>> so tests throw exception. > >>>> The timeout can be removed at all (so timeouts would be handled by > >>>> general jtreg timeout mechanism), but prefer keep smaller timeout > >>>> for > >>>> jdb reply, but apply timefactor to the value. > >>>> > >>>> Also the change fixes > >>>> https://bugs.openjdk.java.net/browse/JDK-8210748 > >>>> - in the case of error additional logging is done to indicate > >>>> certain > >>>> point where the error occurs. > >>>> > >>>> --alex > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Thanks, > >>>> Jc > >>> > >> > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 20 15:56:41 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 20 Sep 2018 08:56:41 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <48a98692-fa59-d445-de36-434220618e98@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> Message-ID: Hi Alex, Done here, thanks for the review: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 Thanks again! Jc On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov wrote: > Hi Jc, > > Looks good to me. > A minor note: > - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid global > namespece pollution (ErrorHandler is too generic name). > > --alex > > On 09/19/2018 15:56, JC Beyler wrote: > > Hi Alex, > > > > I've updated the webrev to: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > That webrev has the code that is shown here in snippets. > > > > > > Thanks for the reviews, I've relatively followed your reviews except for > > one detail due to me wanting to handle the NSK_JNI_VERIFY macros via > > this system as well later down the road. For an example: > > > > We currently have in the code: > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = NSK_CPP_STUB2(GetObjectClass, > > pEnv, mhToCall)) != NULL) ) > > > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor (JDK-8210728) > > to: > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = pEnv->GetObjectClass(pEnv, > > mhToCall)) != NULL) ) > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it becomes via > > this wrapping of JNIEnv: > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > > > > 3) Then, via removing the assignment, we'd arrive to a: > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > if (!mhClass) > > > > Without any loss of checking for failures, etc. > > > > So that is my motivation for most of this work with a concrete example > > (hopefully it helps drive this conversation). > > > > I inlined my answers here, let me know what you think. > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > Updated tests looks good. > > Some notes about implementation. > > > > - FatalOnException implements both verification and error handling > > It would be better to separate them (and this makes easy to implement > > error handling different from JNIEnv::FatalError). > > The simplest way is to define error handler as > > class SafeJNIEnv { > > public: > > typedef void (*ErrorHandler)(JNIEnv *env, const char* > errorMsg); > > // error handler which terminates jvm by using FatalError() > > static void FatalError(JNIEnv *env, const char *errrorMsg); > > > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler errorHandler = > > FatalError); > > (SafeJNIEnv methods should create FatalOnException objects passing > > errorHandler) > > > > > > > > Agreed, I tried to keep the code simple. The concepts you talk about > > here are generally what I reserve for when I need it (ie extensions and > > handling new cases). But a lot are going to be needed soon so I think it > > is a good time to iron the code out now on this "simple" webrev. > > > > So done for this. > > > > > > > > - FatalOnException is used in SafeJNIEnv methods as > > FatalOnException marker(this, "msg"); > > ret = > > (optional)marker.check_for_null(ret); > > return ret; > > But actually I'd call it something like JNICallResultVerifier and > > create > > the object after JNI call. like > > ret = > > JNICallResultVerifier(this, "msg") > > (optional).notNull(ret); > > return ret; > > or even (if you like such syntax sugar) you can define > > template > > T resultNotNull(T result) { > > notNull(result); > > return result; > > } > > and do > > ret = > > return JNICallResultVerifier(this, "msg").resultNotNull(ret); > > > > > > So I renamed FatalOnException to now being JNIVerifier. > > > > Though I like it, I don't think we can do it, except if we do it > > slightly differently: > > I'm trying to solve two problems with one stone: > > - How to check for returns of JNI calls in the way that is done here > > - How to remove NSK_JNI_VERIFY* (from nsk/share/jni/jni_tools) > > > > However, the NSK_JNI_VERIFY need to start a tracing system before the > > call to JNI, so it won't work this way. (Side question would be do we > > still care about the tracing in NSK_JNI_VERIFY, if we don't then your > > solution works well in most situations). > > > > My vision or intuition is that we would throw a template at some point > > on SafeJNIEnv to handle both cases and have JNIVerifier become a > > specialization in certain cases and something different for the > > NSK_JNI_VERIFY case (or have a different constructor to enable tracing). > > But for now, I offer the implementation that does: > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > > JNIVerifier marker(this, "GetObjectClass"); > > return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > } > > > > and: > > > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID field, jobject > > value) { > > JNIVerifier<> marker(this, "SetObjectField"); > > _jni_env->SetObjectField(obj, field, value); > > } > > > > > > > > > > - you added #include in the test (and you have to add it to > > every test). > > It would be simpler to add the include to SafeJNIEnv.hpp and define > > typedef std::unique_ptr SafeJNIEnvPtr; > > Then each in the test methods: > > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > > or you can add > > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, ErrorHandler > > errorHandler = fatalError) > > and get > > SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > > > > > > Done, I like that, even less code change to tests then. > > > > > > > > - it would be better to wrap internal classes (FatalOnException) into > > unnamed namespace - this helps to avoid conflicts with other classes) > > > > - FatalOnException::check_for_null(void* ptr) > > should be > > FatalOnException::check_for_null(const void* ptr) > > And calling the method you don't need reinterpret_cast > > > > > > Also done, it got renamed to ResultNotNull, is using a template now, but > > agreed, that worked. > > Thanks again for the review, > > Jc > > > > > > --alex > > > > > > On 09/18/2018 11:07, JC Beyler wrote: > > > Hi David, > > > > > > Thanks for the quick review and thoughts. I have now a new > > version here > > > that addresses your comments: > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > I've also inlined my answers/comments. > > > > > > > > > > > > > I've slowly started working on JDK-8191519 > > > > . > > However before > > > > starting to really refactor all the tests, I thought I'd > > get a few > > > > opinions. I am working on internalizing the error handling > > of JNI > > > calls > > > > via a SafeJNIEnv class that redefines all the JNI calls to > > add an > > > error > > > > checker. > > > > > > > > The advantage is that the test code will look and feel like > > > normal JNI > > > > code and calls but will have the checks we want to have > > for our > > > tests. > > > > > > Not sure I get that. Normal JNI code has to check for > > errors/exceptions > > > after every call. The tests need those checks too. Today they > are > > > explicit, with this change they become implicit. Not sure > > what we are > > > gaining here ?? > > > > > > > > > In my humble opinion, having the error checking out of the way > > allows > > > the code reader to concentrate on the JNI code while maintaining > > error > > > checking. We use something similar internally, so perhaps I'm > > biased to > > > it :-). > > > If this is not a desired/helpful "feature" to simplify tests in > > general, > > > I will backtrack it and just add the explicit tests to the native > > code > > > of the locks for the fix > > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > > > Let me however try to make my case and let me know what you all > > think! > > > > > > > > > > If agreed with this, we can augment the SafeJNIEnv class > > as needed. > > > > Also, if the tests require something else than fatal > > errors, we > > > can add > > > > a different marker and make it a parameter to the base > class. > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > Let me know what you think, > > > > > > Two initial suggestions: > > > > > > 1. FatalOnException should be constructed with a description > > string so > > > that it can report the failing operation when calling > > FatalError rather > > > than the general "Problem with a JNI call". > > > > > > > > > Agreed with you, the new webrev produces: > > > > > > FATAL ERROR in native method: GetObjectClass > > > at > > > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > > at > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > Method) > > > at > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > at > > > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > > at > > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > > > > and for a return NULL in NewGlobalRef, we would get automatically: > > > > > > FATAL ERROR in native method: NewGlobalRef:Return is NULL > > > at > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > Method) > > > > > > at > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > > > > > > Again as we port and simplify more tests (I'll only do the locks > > for now > > > and we can figure out the next steps as start working on moving > > tests > > > out of vmTestbase), > > > we can add, if needed, other exception handlers that don't throw > > or do > > > other things depending on the JNI method outputs. > > > > > > > > > 2. Make the local SafeJNIEnv a pointer called env so that the > > change is > > > less disruptive. All the env->op() calls will remain and only > > the local > > > error checking will be removed. > > > > > > > > > Done, I used a unique_ptr to make the object > > created/destroyed/available > > > as a pointer do-able in one line: > > > std::unique_ptr env(new SafeJNIEnv(jni_env)); > > > > > > and then you can see that, as you mentioned, the disruption to > > the code > > > is much less: > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > Basically the tests now become internal to the SafeJNIEnv and the > > code > > > now only contains the JNI calls happening but we are protected > > and will > > > fail any test that has an exception or a NULL return for the > > call. Of > > > course, this is not 100% proof in terms of not having any error > > handling > > > in the test but in some cases like this, the new code seems to > > just work > > > better: > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > The switch from, e.g., checking NULL returns to checking for > > pending > > > exceptions, need to be sure that the JNI operations clearly > > specify > > > that > > > NULL implies there will be an exception pending. This change > > may be an > > > issue for static code analysis if not smart enough to > > understand the > > > RAII wrappers. > > > > > > > > > Agreed, I fixed it to be more strict and say: in normal test > > handling, > > > the JNI calls should never return NULL or throw an exception. This > > > should hold for tests I imagine but if not we can add a different > > call > > > verifier as we go. > > > > > > > > > Thanks, > > > David > > > > > > > Jc > > > > > > > > > > > > Let me know what you all think. When talking about it a bit, I had > > > gotten some interest to see what it would look like. Here it is > > :-). Now > > > if it is not wanted like I said, I can backtrack and just put the > > error > > > checks after each JNI call for all the tests as we are porting > them. > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Thu Sep 20 17:24:41 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 20 Sep 2018 10:24:41 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> Message-ID: Looks like JDK-4660756 fixed line number, but didn't fix source. I filled JDK-8210927 for this. New webrev: http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.02/ changes (vs ver .01): - updated comment in StringConvertTest.java about arrays; - RedefineTTYLineNumber was updated to verify line numbers, verification of the source at breakpoint is added, but commented out (should be uncommented by fix for JDK-8210927) --alex On 09/14/2018 18:09, Chris Plummer wrote: > Hmm. I thought that's what the original bug was addressing. > > ? 27? * @summary TTY: Need to clear source cache after doing a redefine > class > > Chris > > On 9/14/18 4:37 PM, Alex Menkov wrote: >> Looks like only line numbers are reported correctly, but the content >> of the line content if not correct :) >> >> [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), >> line=47 bci=0 >> [jdb] 47??????????? System.out.println("in A, about to call B"); >> [jdb] >> [jdb] main[1] >> >> [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), >> line=46 bci=0 >> [jdb] 46??????? public void A() { >> [jdb] >> [jdb] main[1] >> >> "public void A()" is a line 46 in the original file >> >> --alex >> >> On 09/14/2018 15:32, Chris Plummer wrote: >>> I think checking the output after the second breakpoint would be a >>> good idea. However, rather than checking the line number, maybe just >>> check the contents of the line, which should be included in the >>> breakpoint event output. >>> >>> Chris >>> >>> On 9/14/18 3:23 PM, Alex Menkov wrote: >>>> Hi Chris, >>>> >>>> The file history does not contain any info about line number >>>> dependency. >>>> I'll remove "11 before, 10 afterward" comment. >>>> Actually the test is not clear to me. >>>> Accordingly the test description jdb report obsolete line number in >>>> the case, but the test does not verify its correctness, but just >>>> checks _debuggee_ (not jdb) output for absence of "Internal exception". >>>> The original bug is ancient, so it's hard to say if the test is >>>> correct or not. >>>> I can add extra testing - extract reported line numbers (by using >>>> regexp "line=(\d+)\b") and verify that 2st breakpoint is reported >>>> with the expected line number (1 less than line of the 1st breakpoint). >>>> Thoughts? >>>> >>>> --alex >>>> >>>> On 09/14/2018 14:27, Chris Plummer wrote: >>>>> Hi Alex, >>>>> >>>>> Just one issue I see. For RedefineTTYLineNumber.java, the original >>>>> test used to have this comment, which your removed: >>>>> >>>>> ?? 52?? // line number sensitive!!! Next line must be line 10. >>>>> >>>>> It's not clear to me why this test was ever line number sensitive, >>>>> and whether you removed this sensitivity, or it just never existed. >>>>> In any case, you left in the following comment, which maybe should >>>>> also be removed: >>>>> >>>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>>> before, 10 afterward >>>>> >>>>> Also, the println output from A() does not seem to match what the >>>>> test is doing. There is no call to B(): >>>>> >>>>> ?? 46???? public void A() { >>>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>>> before, 10 afterward >>>>> ?? 48???????? System.out.println("out from B"); >>>>> ?? 49???? } >>>>> >>>>> Maybe that's some bit rot. My understanding of the point of the >>>>> test is while at the breakpoint at the start of A(), a redefine is >>>>> done that deletes a line above this point, and jdi needs to make >>>>> the appropriate adjustment of the current breakpoint line number. >>>>> So calling B() does not play a roll in this, but perhaps it did a >>>>> one point but the call was removed. >>>>> >>>>> Also, I don't see any indication of line number sensitivity here, >>>>> but once again, maybe this is a bit rot issue and at one point it >>>>> was line number sensitive. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 9/14/18 12:59 PM, Alex Menkov wrote: >>>>>> Hi all, >>>>>> >>>>>> please review fix for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>>>>> >>>>>> --alex >>>>> >>>>> >>>>> >>> >>> > > From gary.adams at oracle.com Thu Sep 20 17:54:50 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 20 Sep 2018 13:54:50 -0400 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" Message-ID: <5BA3DEEA.9070604@oracle.com> The corrupted output has been identified due to the "Boolean[1]" being misrecognized as a compound prompt. The proposed fix waits for the correct prompt before advancing to the next command. Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 Testing is in progress. From gary.adams at oracle.com Thu Sep 20 17:59:26 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 20 Sep 2018 13:59:26 -0400 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again Message-ID: <5BA3DFFE.5090201@oracle.com> The test failure has been identified due to the "int[2]" being misrecognized as a compound prompt. This caused a cont command to be sent prematurely. The proposed fix waits for the correct prompt before advancing to the next command. Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 Testing is in progress. From chris.plummer at oracle.com Thu Sep 20 21:47:48 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 14:47:48 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <5BA3DFFE.5090201@oracle.com> References: <5BA3DFFE.5090201@oracle.com> Message-ID: Looks good. Still not bullet proof, but I'm not sure it's possible to write tests like this in a way that will work no matter what output is produced by the method enter/exit events. Chris On 9/20/18 10:59 AM, Gary Adams wrote: > The test failure has been identified due to the "int[2]" > being misrecognized as a compound prompt.? This caused a cont > command to be sent prematurely. > > The proposed fix waits for the correct prompt before > advancing to the next command. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 > > Testing is in progress. From chris.plummer at oracle.com Thu Sep 20 21:50:05 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 14:50:05 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <5BA3DEEA.9070604@oracle.com> References: <5BA3DEEA.9070604@oracle.com> Message-ID: <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> This one is a little different than exclude001 in that we don't control the name of the thread. We know (at least at the moment) that it is called "main", but that could always change. In general I'm fine with this fix, but if you have others like it, I'd suggest putting the "main" thread name in single place, not in each test that cares about it. Chris On 9/20/18 10:54 AM, Gary Adams wrote: > The corrupted output has been identified due to the "Boolean[1]" > being misrecognized as a compound prompt. > > The proposed fix waits for the correct prompt before > advancing to the next command. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 > > Testing is in progress. From chris.plummer at oracle.com Thu Sep 20 22:07:23 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 15:07:23 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> Message-ID: <9b1677ce-c128-fc7c-f88b-77071c1ca486@oracle.com> Hi Alex, Can you put "expected statement printed by jdb" in a static final since it is used in 2 places? Otherwise it looks good. I don't need to see an updated webrev. thanks, Chris On 9/20/18 10:24 AM, Alex Menkov wrote: > Looks like JDK-4660756 fixed line number, but didn't fix source. > I filled JDK-8210927 for this. > > New webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.02/ > changes (vs ver .01): > - updated comment in StringConvertTest.java about arrays; > - RedefineTTYLineNumber was updated to verify line numbers, > ? verification of the source at breakpoint is added, but commented out > (should be uncommented by fix for JDK-8210927) > > --alex > > On 09/14/2018 18:09, Chris Plummer wrote: >> Hmm. I thought that's what the original bug was addressing. >> >> ?? 27? * @summary TTY: Need to clear source cache after doing a >> redefine class >> >> Chris >> >> On 9/14/18 4:37 PM, Alex Menkov wrote: >>> Looks like only line numbers are reported correctly, but the content >>> of the line content if not correct :) >>> >>> [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), >>> line=47 bci=0 >>> [jdb] 47??????????? System.out.println("in A, about to call B"); >>> [jdb] >>> [jdb] main[1] >>> >>> [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), >>> line=46 bci=0 >>> [jdb] 46??????? public void A() { >>> [jdb] >>> [jdb] main[1] >>> >>> "public void A()" is a line 46 in the original file >>> >>> --alex >>> >>> On 09/14/2018 15:32, Chris Plummer wrote: >>>> I think checking the output after the second breakpoint would be a >>>> good idea. However, rather than checking the line number, maybe >>>> just check the contents of the line, which should be included in >>>> the breakpoint event output. >>>> >>>> Chris >>>> >>>> On 9/14/18 3:23 PM, Alex Menkov wrote: >>>>> Hi Chris, >>>>> >>>>> The file history does not contain any info about line number >>>>> dependency. >>>>> I'll remove "11 before, 10 afterward" comment. >>>>> Actually the test is not clear to me. >>>>> Accordingly the test description jdb report obsolete line number >>>>> in the case, but the test does not verify its correctness, but >>>>> just checks _debuggee_ (not jdb) output for absence of "Internal >>>>> exception". >>>>> The original bug is ancient, so it's hard to say if the test is >>>>> correct or not. >>>>> I can add extra testing - extract reported line numbers (by using >>>>> regexp "line=(\d+)\b") and verify that 2st breakpoint is reported >>>>> with the expected line number (1 less than line of the 1st >>>>> breakpoint). >>>>> Thoughts? >>>>> >>>>> --alex >>>>> >>>>> On 09/14/2018 14:27, Chris Plummer wrote: >>>>>> Hi Alex, >>>>>> >>>>>> Just one issue I see. For RedefineTTYLineNumber.java, the >>>>>> original test used to have this comment, which your removed: >>>>>> >>>>>> ?? 52?? // line number sensitive!!! Next line must be line 10. >>>>>> >>>>>> It's not clear to me why this test was ever line number >>>>>> sensitive, and whether you removed this sensitivity, or it just >>>>>> never existed. In any case, you left in the following comment, >>>>>> which maybe should also be removed: >>>>>> >>>>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>>>> before, 10 afterward >>>>>> >>>>>> Also, the println output from A() does not seem to match what the >>>>>> test is doing. There is no call to B(): >>>>>> >>>>>> ?? 46???? public void A() { >>>>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>>>> before, 10 afterward >>>>>> ?? 48???????? System.out.println("out from B"); >>>>>> ?? 49???? } >>>>>> >>>>>> Maybe that's some bit rot. My understanding of the point of the >>>>>> test is while at the breakpoint at the start of A(), a redefine >>>>>> is done that deletes a line above this point, and jdi needs to >>>>>> make the appropriate adjustment of the current breakpoint line >>>>>> number. So calling B() does not play a roll in this, but perhaps >>>>>> it did a one point but the call was removed. >>>>>> >>>>>> Also, I don't see any indication of line number sensitivity here, >>>>>> but once again, maybe this is a bit rot issue and at one point it >>>>>> was line number sensitive. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/14/18 12:59 PM, Alex Menkov wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review fix for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>>>>>> >>>>>>> --alex >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From alexey.menkov at oracle.com Thu Sep 20 22:22:43 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 20 Sep 2018 15:22:43 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> Message-ID: <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> May be it would be better to fix Jdb.receiveReplyFor to properly handle all replies like Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be instance of java.lang.Boolean[1] (id=706): jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or test/jdk/com/sun/jdi/ShellScaffold.sh) AFAIR nsk/../Jdb does not use regexp, but I believe it can be updated to work the same way. --alex On 09/20/2018 14:50, Chris Plummer wrote: > This one is a little different than exclude001 in that we don't control > the name of the thread. We know (at least at the moment) that it is > called "main", but that could always change. In general I'm fine with > this fix, but if you have others like it, I'd suggest putting the "main" > thread name in single place, not in each test that cares about it. > > Chris > > On 9/20/18 10:54 AM, Gary Adams wrote: >> The corrupted output has been identified due to the "Boolean[1]" >> being misrecognized as a compound prompt. >> >> The proposed fix waits for the correct prompt before >> advancing to the next command. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >> >> Testing is in progress. > > > From chris.plummer at oracle.com Thu Sep 20 22:27:22 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 15:27:22 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> Message-ID: <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> The regex you give would still detect Boolean[1] as a prompt, which we don't want. Chris On 9/20/18 3:22 PM, Alex Menkov wrote: > May be it would be better to fix Jdb.receiveReplyFor to properly > handle all replies like > Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be > instance of java.lang.Boolean[1] (id=706): > > jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: > "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" > (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or > test/jdk/com/sun/jdi/ShellScaffold.sh) > AFAIR nsk/../Jdb does not use regexp, but I believe it can be updated > to work the same way. > > --alex > > > On 09/20/2018 14:50, Chris Plummer wrote: >> This one is a little different than exclude001 in that we don't >> control the name of the thread. We know (at least at the moment) that >> it is called "main", but that could always change. In general I'm >> fine with this fix, but if you have others like it, I'd suggest >> putting the "main" thread name in single place, not in each test that >> cares about it. >> >> Chris >> >> On 9/20/18 10:54 AM, Gary Adams wrote: >>> The corrupted output has been identified due to the "Boolean[1]" >>> being misrecognized as a compound prompt. >>> >>> The proposed fix waits for the correct prompt before >>> advancing to the next command. >>> >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >>> >>> Testing is in progress. >> >> >> From chris.plummer at oracle.com Thu Sep 20 22:52:24 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 15:52:24 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: References: <5BA3DFFE.5090201@oracle.com> Message-ID: <2685cb53-a813-fb20-2249-e68a8500cc19@oracle.com> BTW, this CR is still covering the kill002 failure, so you need to either include a fix for it also, or create a separate CR for it. I think a separate CR would be best because it is a different root cause. Chris On 9/20/18 2:47 PM, Chris Plummer wrote: > Looks good. Still not bullet proof, but I'm not sure it's possible to > write tests like this in a way that will work no matter what output is > produced by the method enter/exit events. > > Chris > > On 9/20/18 10:59 AM, Gary Adams wrote: >> The test failure has been identified due to the "int[2]" >> being misrecognized as a compound prompt.? This caused a cont >> command to be sent prematurely. >> >> The proposed fix waits for the correct prompt before >> advancing to the next command. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >> >> Testing is in progress. > > > From alexey.menkov at oracle.com Thu Sep 20 23:06:40 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 20 Sep 2018 16:06:40 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> Message-ID: <2d2838bf-5183-2b36-7b46-4044c18eccb6@oracle.com> To be detected the output line should ends with "Boolean[1] " So "Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be instance of java.lang.Boolean[1] (id=706):" does not match. It seems to me that other bugs Gary is working have similar cases. --alex On 09/20/2018 15:27, Chris Plummer wrote: > The regex you give would still detect Boolean[1] as a prompt, which we > don't want. > > Chris > > On 9/20/18 3:22 PM, Alex Menkov wrote: >> May be it would be better to fix Jdb.receiveReplyFor to properly >> handle all replies like >> Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be >> instance of java.lang.Boolean[1] (id=706): >> >> jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: >> "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" >> (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or >> test/jdk/com/sun/jdi/ShellScaffold.sh) >> AFAIR nsk/../Jdb does not use regexp, but I believe it can be updated >> to work the same way. >> >> --alex >> >> >> On 09/20/2018 14:50, Chris Plummer wrote: >>> This one is a little different than exclude001 in that we don't >>> control the name of the thread. We know (at least at the moment) that >>> it is called "main", but that could always change. In general I'm >>> fine with this fix, but if you have others like it, I'd suggest >>> putting the "main" thread name in single place, not in each test that >>> cares about it. >>> >>> Chris >>> >>> On 9/20/18 10:54 AM, Gary Adams wrote: >>>> The corrupted output has been identified due to the "Boolean[1]" >>>> being misrecognized as a compound prompt. >>>> >>>> The proposed fix waits for the correct prompt before >>>> advancing to the next command. >>>> >>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >>>> >>>> Testing is in progress. >>> >>> >>> > > From alexey.menkov at oracle.com Thu Sep 20 23:11:14 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 20 Sep 2018 16:11:14 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <9b1677ce-c128-fc7c-f88b-77071c1ca486@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> <9b1677ce-c128-fc7c-f88b-77071c1ca486@oracle.com> Message-ID: <96829ad5-7d64-7336-5dc0-d7e6d2a0de91@oracle.com> Hi Chris, On 09/20/2018 15:07, Chris Plummer wrote: > Hi Alex, > > Can you put "expected statement printed by jdb" in a static final since > it is used in 2 places? Otherwise it looks good. I don't need to see an > updated webrev. Not sure how it can be done. The text has to be explicitly specified in the 1st line of RedefineTTYLineNumberTarg.A method (as jdb prints the source). --alex > > thanks, > > Chris > > On 9/20/18 10:24 AM, Alex Menkov wrote: >> Looks like JDK-4660756 fixed line number, but didn't fix source. >> I filled JDK-8210927 for this. >> >> New webrev: >> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.02/ >> changes (vs ver .01): >> - updated comment in StringConvertTest.java about arrays; >> - RedefineTTYLineNumber was updated to verify line numbers, >> ? verification of the source at breakpoint is added, but commented out >> (should be uncommented by fix for JDK-8210927) >> >> --alex >> >> On 09/14/2018 18:09, Chris Plummer wrote: >>> Hmm. I thought that's what the original bug was addressing. >>> >>> ?? 27? * @summary TTY: Need to clear source cache after doing a >>> redefine class >>> >>> Chris >>> >>> On 9/14/18 4:37 PM, Alex Menkov wrote: >>>> Looks like only line numbers are reported correctly, but the content >>>> of the line content if not correct :) >>>> >>>> [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), >>>> line=47 bci=0 >>>> [jdb] 47??????????? System.out.println("in A, about to call B"); >>>> [jdb] >>>> [jdb] main[1] >>>> >>>> [jdb] Breakpoint hit: "thread=main", RedefineTTYLineNumberTarg.A(), >>>> line=46 bci=0 >>>> [jdb] 46??????? public void A() { >>>> [jdb] >>>> [jdb] main[1] >>>> >>>> "public void A()" is a line 46 in the original file >>>> >>>> --alex >>>> >>>> On 09/14/2018 15:32, Chris Plummer wrote: >>>>> I think checking the output after the second breakpoint would be a >>>>> good idea. However, rather than checking the line number, maybe >>>>> just check the contents of the line, which should be included in >>>>> the breakpoint event output. >>>>> >>>>> Chris >>>>> >>>>> On 9/14/18 3:23 PM, Alex Menkov wrote: >>>>>> Hi Chris, >>>>>> >>>>>> The file history does not contain any info about line number >>>>>> dependency. >>>>>> I'll remove "11 before, 10 afterward" comment. >>>>>> Actually the test is not clear to me. >>>>>> Accordingly the test description jdb report obsolete line number >>>>>> in the case, but the test does not verify its correctness, but >>>>>> just checks _debuggee_ (not jdb) output for absence of "Internal >>>>>> exception". >>>>>> The original bug is ancient, so it's hard to say if the test is >>>>>> correct or not. >>>>>> I can add extra testing - extract reported line numbers (by using >>>>>> regexp "line=(\d+)\b") and verify that 2st breakpoint is reported >>>>>> with the expected line number (1 less than line of the 1st >>>>>> breakpoint). >>>>>> Thoughts? >>>>>> >>>>>> --alex >>>>>> >>>>>> On 09/14/2018 14:27, Chris Plummer wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> Just one issue I see. For RedefineTTYLineNumber.java, the >>>>>>> original test used to have this comment, which your removed: >>>>>>> >>>>>>> ?? 52?? // line number sensitive!!! Next line must be line 10. >>>>>>> >>>>>>> It's not clear to me why this test was ever line number >>>>>>> sensitive, and whether you removed this sensitivity, or it just >>>>>>> never existed. In any case, you left in the following comment, >>>>>>> which maybe should also be removed: >>>>>>> >>>>>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>>>>> before, 10 afterward >>>>>>> >>>>>>> Also, the println output from A() does not seem to match what the >>>>>>> test is doing. There is no call to B(): >>>>>>> >>>>>>> ?? 46???? public void A() { >>>>>>> ?? 47???????? System.out.println("in A, about to call B"); // 11 >>>>>>> before, 10 afterward >>>>>>> ?? 48???????? System.out.println("out from B"); >>>>>>> ?? 49???? } >>>>>>> >>>>>>> Maybe that's some bit rot. My understanding of the point of the >>>>>>> test is while at the breakpoint at the start of A(), a redefine >>>>>>> is done that deletes a line above this point, and jdi needs to >>>>>>> make the appropriate adjustment of the current breakpoint line >>>>>>> number. So calling B() does not play a roll in this, but perhaps >>>>>>> it did a one point but the call was removed. >>>>>>> >>>>>>> Also, I don't see any indication of line number sensitivity here, >>>>>>> but once again, maybe this is a bit rot issue and at one point it >>>>>>> was line number sensitive. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/14/18 12:59 PM, Alex Menkov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> please review fix for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>>>>>>> >>>>>>>> --alex >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From chris.plummer at oracle.com Fri Sep 21 00:17:11 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 17:17:11 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <2d2838bf-5183-2b36-7b46-4044c18eccb6@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> <2d2838bf-5183-2b36-7b46-4044c18eccb6@oracle.com> Message-ID: <10437553-2276-8b88-9189-493b4c5b4d89@oracle.com> Ok, so you're just suggesting that findPrompt() should require that the prompt be at the end of the line. In fact probably on a line by itself. Keep in mind that we also have issues with async printing that tends to result in the prompt appearing in the middle of some lines. We have most of these situations understood and under control now, but I'm guessing they still turn up in some places, and would cause findPrompt() to fail. Chris On 9/20/18 4:06 PM, Alex Menkov wrote: > To be detected the output line should ends with "Boolean[1] " > > So "Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will > be instance of java.lang.Boolean[1] (id=706):" does not match. > It seems to me that other bugs Gary is working have similar cases. > > --alex > > On 09/20/2018 15:27, Chris Plummer wrote: >> The regex you give would still detect Boolean[1] as a prompt, which >> we don't want. >> >> Chris >> >> On 9/20/18 3:22 PM, Alex Menkov wrote: >>> May be it would be better to fix Jdb.receiveReplyFor to properly >>> handle all replies like >>> Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be >>> instance of java.lang.Boolean[1] (id=706): >>> >>> jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: >>> "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" >>> (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or >>> test/jdk/com/sun/jdi/ShellScaffold.sh) >>> AFAIR nsk/../Jdb does not use regexp, but I believe it can be >>> updated to work the same way. >>> >>> --alex >>> >>> >>> On 09/20/2018 14:50, Chris Plummer wrote: >>>> This one is a little different than exclude001 in that we don't >>>> control the name of the thread. We know (at least at the moment) >>>> that it is called "main", but that could always change. In general >>>> I'm fine with this fix, but if you have others like it, I'd suggest >>>> putting the "main" thread name in single place, not in each test >>>> that cares about it. >>>> >>>> Chris >>>> >>>> On 9/20/18 10:54 AM, Gary Adams wrote: >>>>> The corrupted output has been identified due to the "Boolean[1]" >>>>> being misrecognized as a compound prompt. >>>>> >>>>> The proposed fix waits for the correct prompt before >>>>> advancing to the next command. >>>>> >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >>>>> >>>>> Testing is in progress. >>>> >>>> >>>> >> >> From chris.plummer at oracle.com Fri Sep 21 00:17:17 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 20 Sep 2018 17:17:17 -0700 Subject: RFR JDK-8210760: [TEST] rewrite com/sun/jdi shell tests to java version - step4 In-Reply-To: <96829ad5-7d64-7336-5dc0-d7e6d2a0de91@oracle.com> References: <42f3addb-dbf6-0bdf-a623-d33266b0e880@oracle.com> <611091b8-203c-98bd-5273-6062d61ee541@oracle.com> <3234cb9d-7782-2117-b881-b5ac76748f8d@oracle.com> <09225fc5-2c04-3af4-2d96-04be8c79a7d1@oracle.com> <9b1677ce-c128-fc7c-f88b-77071c1ca486@oracle.com> <96829ad5-7d64-7336-5dc0-d7e6d2a0de91@oracle.com> Message-ID: <94b6a847-3f53-6869-4af6-8386682f1e33@oracle.com> On 9/20/18 4:11 PM, Alex Menkov wrote: > Hi Chris, > > On 09/20/2018 15:07, Chris Plummer wrote: >> Hi Alex, >> >> Can you put "expected statement printed by jdb" in a static final >> since it is used in 2 places? Otherwise it looks good. I don't need >> to see an updated webrev. > > Not sure how it can be done. > The text has to be explicitly specified in the 1st line of > RedefineTTYLineNumberTarg.A method (as jdb prints the source). Ah, of course. Looks fine as-is then. Chris > > --alex > >> >> thanks, >> >> Chris >> >> On 9/20/18 10:24 AM, Alex Menkov wrote: >>> Looks like JDK-4660756 fixed line number, but didn't fix source. >>> I filled JDK-8210927 for this. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.02/ >>> changes (vs ver .01): >>> - updated comment in StringConvertTest.java about arrays; >>> - RedefineTTYLineNumber was updated to verify line numbers, >>> ? verification of the source at breakpoint is added, but commented >>> out (should be uncommented by fix for JDK-8210927) >>> >>> --alex >>> >>> On 09/14/2018 18:09, Chris Plummer wrote: >>>> Hmm. I thought that's what the original bug was addressing. >>>> >>>> ?? 27? * @summary TTY: Need to clear source cache after doing a >>>> redefine class >>>> >>>> Chris >>>> >>>> On 9/14/18 4:37 PM, Alex Menkov wrote: >>>>> Looks like only line numbers are reported correctly, but the >>>>> content of the line content if not correct :) >>>>> >>>>> [jdb] Breakpoint hit: "thread=main", >>>>> RedefineTTYLineNumberTarg.A(), line=47 bci=0 >>>>> [jdb] 47??????????? System.out.println("in A, about to call B"); >>>>> [jdb] >>>>> [jdb] main[1] >>>>> >>>>> [jdb] Breakpoint hit: "thread=main", >>>>> RedefineTTYLineNumberTarg.A(), line=46 bci=0 >>>>> [jdb] 46??????? public void A() { >>>>> [jdb] >>>>> [jdb] main[1] >>>>> >>>>> "public void A()" is a line 46 in the original file >>>>> >>>>> --alex >>>>> >>>>> On 09/14/2018 15:32, Chris Plummer wrote: >>>>>> I think checking the output after the second breakpoint would be >>>>>> a good idea. However, rather than checking the line number, maybe >>>>>> just check the contents of the line, which should be included in >>>>>> the breakpoint event output. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/14/18 3:23 PM, Alex Menkov wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> The file history does not contain any info about line number >>>>>>> dependency. >>>>>>> I'll remove "11 before, 10 afterward" comment. >>>>>>> Actually the test is not clear to me. >>>>>>> Accordingly the test description jdb report obsolete line number >>>>>>> in the case, but the test does not verify its correctness, but >>>>>>> just checks _debuggee_ (not jdb) output for absence of "Internal >>>>>>> exception". >>>>>>> The original bug is ancient, so it's hard to say if the test is >>>>>>> correct or not. >>>>>>> I can add extra testing - extract reported line numbers (by >>>>>>> using regexp "line=(\d+)\b") and verify that 2st breakpoint is >>>>>>> reported with the expected line number (1 less than line of the >>>>>>> 1st breakpoint). >>>>>>> Thoughts? >>>>>>> >>>>>>> --alex >>>>>>> >>>>>>> On 09/14/2018 14:27, Chris Plummer wrote: >>>>>>>> Hi Alex, >>>>>>>> >>>>>>>> Just one issue I see. For RedefineTTYLineNumber.java, the >>>>>>>> original test used to have this comment, which your removed: >>>>>>>> >>>>>>>> ?? 52?? // line number sensitive!!! Next line must be line 10. >>>>>>>> >>>>>>>> It's not clear to me why this test was ever line number >>>>>>>> sensitive, and whether you removed this sensitivity, or it just >>>>>>>> never existed. In any case, you left in the following comment, >>>>>>>> which maybe should also be removed: >>>>>>>> >>>>>>>> ?? 47???????? System.out.println("in A, about to call B"); // >>>>>>>> 11 before, 10 afterward >>>>>>>> >>>>>>>> Also, the println output from A() does not seem to match what >>>>>>>> the test is doing. There is no call to B(): >>>>>>>> >>>>>>>> ?? 46???? public void A() { >>>>>>>> ?? 47???????? System.out.println("in A, about to call B"); // >>>>>>>> 11 before, 10 afterward >>>>>>>> ?? 48???????? System.out.println("out from B"); >>>>>>>> ?? 49???? } >>>>>>>> >>>>>>>> Maybe that's some bit rot. My understanding of the point of the >>>>>>>> test is while at the breakpoint at the start of A(), a redefine >>>>>>>> is done that deletes a line above this point, and jdi needs to >>>>>>>> make the appropriate adjustment of the current breakpoint line >>>>>>>> number. So calling B() does not play a roll in this, but >>>>>>>> perhaps it did a one point but the call was removed. >>>>>>>> >>>>>>>> Also, I don't see any indication of line number sensitivity >>>>>>>> here, but once again, maybe this is a bit rot issue and at one >>>>>>>> point it was line number sensitive. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/14/18 12:59 PM, Alex Menkov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> please review fix for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210760 >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~amenkov/sh2java/step4/webrev.01/ >>>>>>>>> >>>>>>>>> --alex >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From gary.adams at oracle.com Fri Sep 21 00:34:59 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 20 Sep 2018 20:34:59 -0400 Subject: Ping: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> <5B9FF1DC.40806@oracle.com> <5B9FF8FE.6060209@oracle.com> Message-ID: I have no further comments/questions. On 9/20/18 11:52 AM, JC Beyler wrote: > Hi Alex, > > Looks good to me still :) > Jc > > On Wed, Sep 19, 2018 at 5:21 PM Alex Menkov > wrote: > > Hi all, > > Ping. > The bug has been labeled "timewaster" as it caused failures quite > often. > > --alex > > On 09/17/2018 12:57, Alex Menkov wrote: > > Hi Gary, > > > > updated webrev: > > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.02/ > > > > > see comments inline. > > > > On 09/17/2018 11:57, Gary Adams wrote: > >> Should sleepTime also be adjusted? > > > > No. > > sleepTime is delay before we read jdb output (i.e. we don't read > jdb > > output on every update, but check for new data once a second) > > > >> > >> Should sleepTime and timeout be scoped to > >> just waitForPrompt? > > > > They are defined at the block where all constants are defined. > > I made the constants final. > > > >> > >> On 9/17/18, 2:26 PM, Gary Adams wrote: > >>> Is the log decoration typical? > >>> > >>> 98 jdb.log("======================================="); > > > > This is to make clearer the exact point error occurs. > > (I initially tried just log "Exception thrown during test > execution: " + > > e.getMessage(), but it's too inconspicuous) > > > >>> > >>> Is the Utils.adjustTimeout() applied consistently? > >>> e.g. is the timeout passed to waitFor() already adjusted? > > > > waitFor timeouts are adjusted. > > > >>> > >>> If you are promoting log() to be publicly visible, then it > >>> should be used for the other cases of println() in Jdb and > JdbTest. > > > > fixed. > > > > --alex > > > >>> > >>> On 9/17/18, 1:58 PM, JC Beyler wrote: > >>>> Hi Alex, > >>>> > >>>> Looks good to me, > >>>> Jc > >>>> > >>>> On Mon, Sep 17, 2018 at 10:49 AM Alex Menkov > >>>> > >> wrote: > >>>> > >>>> ??? Hi all, > >>>> > >>>> ??? please review small fix: > >>>> > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ > > >>>> ??? > > >>>> > >>>> ??? It fixes > >>>> https://bugs.openjdk.java.net/browse/JDK-8210725 > >>>> ??? - accordingly the logs of the failing tests, they work as > >>>> ??? expected, but > >>>> ??? sometimes (busy environment?) there is no reply from jdb > for 60 > >>>> ??? seconds, > >>>> ??? so tests throw exception. > >>>> ??? The timeout can be removed at all (so timeouts would be > handled by > >>>> ??? general jtreg timeout mechanism), but prefer keep smaller > timeout > >>>> ??? for > >>>> ??? jdb reply, but apply timefactor to the value. > >>>> > >>>> ??? Also the change fixes > >>>> https://bugs.openjdk.java.net/browse/JDK-8210748 > >>>> ??? - in the case of error additional logging is done to indicate > >>>> ??? certain > >>>> ??? point where the error occurs. > >>>> > >>>> ??? --alex > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Thanks, > >>>> Jc > >>> > >> > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Sep 21 01:23:01 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 20 Sep 2018 18:23:01 -0700 Subject: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds In-Reply-To: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> References: <5465e943-ddb1-b287-bd2b-1275cae9ab5f@oracle.com> Message-ID: <6c95a13c-8b9c-9999-b3f0-b46869c1c6ec@oracle.com> Hi Alex, The fix looks good to me. Thanks, Serguei On 9/17/18 10:49 AM, Alex Menkov wrote: > Hi all, > > please review small fix: > http://cr.openjdk.java.net/~amenkov/sh2java/timeout/webrev.01/ > > It fixes > https://bugs.openjdk.java.net/browse/JDK-8210725 > - accordingly the logs of the failing tests, they work as expected, > but sometimes (busy environment?) there is no reply from jdb for 60 > seconds, so tests throw exception. > The timeout can be removed at all (so timeouts would be handled by > general jtreg timeout mechanism), but prefer keep smaller timeout for > jdb reply, but apply timefactor to the value. > > Also the change fixes > https://bugs.openjdk.java.net/browse/JDK-8210748 > - in the case of error additional logging is done to indicate certain > point where the error occurs. > > --alex From daniil.x.titov at oracle.com Fri Sep 21 02:59:27 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 20 Sep 2018 19:59:27 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Message-ID: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However, the consequent call of startListening() methods with unspecified port number fails rather than starts a new listener on auto detected port. This happens since the original argument map passed to the startListening() methods is used as a key to store the mapping to the started listeners. The fix ensures that in cases when the port is auto detected the argument map is updated with the bound port number. Mach5 vmTestbase_nsk_jdi tests successfully passed. Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ Thanks! --Daniil From jcbeyler at google.com Fri Sep 21 03:59:38 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 20 Sep 2018 20:59:38 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> Message-ID: Hi Daniil, I noticed a few nits: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/supportsMultipleConnections/supportsmultipleconnections002.java.html -> You have two 2018 in the copyright http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketListeningConnector.java.udiff.html -> Both new methods have an empty line at the start, is that intended? -> updateArgumentMapIfRequired: you check the length > 0 but assume actually it is > 1 http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/GenericListeningConnector.java.udiff.html -> Same not sure we need the extra line Apart from that it looks good to me. Thanks, Jc On Thu, Sep 20, 2018 at 8:00 PM Daniil Titov wrote: > Please review the change that fixes the issue in > com.sun.tools.jdi.SocketListenerConnector.startListening() method. > > When the argument map passed to startListening() methods has the port > number unspecified or set to zero the port is auto detected. However, the > consequent call of startListening() methods with unspecified port number > fails rather than starts a new listener on auto detected port. This happens > since the original argument map passed to the startListening() methods is > used as a key to store the mapping to the started listeners. > > The fix ensures that in cases when the port is auto detected the argument > map is updated with the bound port number. > > Mach5 vmTestbase_nsk_jdi tests successfully passed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > Thanks! > --Daniil > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Sep 21 07:57:24 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Sep 2018 07:57:24 +0000 Subject: OOM counters In-Reply-To: References: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> Message-ID: * For reference, we added an OOM callback to then do whatever reporting we want to in that case in native; * this allows us to be very careful of not trying to allocate things during an OOM. * HI JC, what callbacks are you referring to exactly ? Best regards, Matthias From: JC Beyler Sent: Donnerstag, 20. September 2018 17:52 To: Baesken, Matthias Cc: David Holmes ; serviceability-dev at openjdk.java.net Subject: Re: OOM counters Hi Matthias, - hotspot-dev to be in two mailing lists I'm still confused of why you want this via a Java API or why you want to look at those counters to begin with. The JVM is going through an OOM, are you trying to do: your program detects it via a try/catch; then go to MemoryMXBean to see what OOM it was? For reference, we added an OOM callback to then do whatever reporting we want to in that case in native; this allows us to be very careful of not trying to allocate things during an OOM. Seems to me that with a callback, you can then do whatever you like, such as adding to your queue for other users to look at afterwards, no? What am I missing? Jc On Wed, Sep 19, 2018 at 11:43 PM Baesken, Matthias > wrote: Hi David , the values are already user-inspectable via jcmd vm.info , however this way is not very user friendly (and I am not sure how stable it is between updates / releases). Probably not as stable as an API . Best regards, Matthias > -----Original Message----- > From: David Holmes > > Sent: Donnerstag, 20. September 2018 03:13 > To: Baesken, Matthias >; 'hotspot- > dev at openjdk.java.net' >; serviceability- > dev at openjdk.java.net serviceability-dev at openjdk.java.net dev at openjdk.java.net> > Subject: Re: OOM counters > > Hi Matthias, > > > Those counters, as I recall, were added to the hs_err report purely to > show if an application/test had been "playing too close to the edge" > before it crashed. They were never intended as user-inspectable values. > > I have no opinion as to whether they should be. > > David > > On 19/09/2018 7:12 PM, Baesken, Matthias wrote: > > Hello, Currently we have already counters in the Hotspot codebase > > counting Java heap, > > > > Metaspace and class metaspace related OOMs. > > > > See declarations: > > > > jdk/src/hotspot/share/utilities/exceptions.hpp > > > > 107 // Count out of memory errors that are interesting in error diagnosis > > > > 108 static volatile int _out_of_memory_error_java_heap_errors; > > > > 109 static volatile int _out_of_memory_error_metaspace_errors; > > > > 110 static volatile int _out_of_memory_error_class_metaspace_errors; > > > > output : > > > > jdk/src/hotspot/share/utilities/exceptions.cpp > > > > 460void Exceptions::print_exception_counts_on_error(outputStream* st) > { > > > > 461 print_oom_count(st, "java_heap_errors", > > _out_of_memory_error_java_heap_errors); > > > > 462 print_oom_count(st, "metaspace_errors", > > _out_of_memory_error_metaspace_errors); > > > > 463 print_oom_count(st, "class_metaspace_errors", > > _out_of_memory_error_class_metaspace_errors); > > > > 464 if (_stack_overflow_errors > 0) { > > > > 465 st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); > > > > 466 } > > > > 467 if (_linkage_errors > 0) { > > > > 468 st->print_cr("LinkageErrors=%d", _linkage_errors); > > > > 469 } > > > > 470} > > > > But currently the output is only done from vmError.cpp , in case of > > > > a) error reporting > > > > b) jcmd vm.info (in case exceptions happened, otherwise the section > > is not printed) > > > > (see void VMError::print_vm_info(outputStream* st) { ... } ) > > > > It would be interesting for us to get the values of the existing > > counters via JDK coding. > > > > In our proprietary JVM we had a similar mechanism. > > > > Is there anything planned for this (or even already something present) ? > > > > There exists already a class java/lang/management/MemoryMXBean.java > > with a management interface for the memory system of > > > > the Java virtual machine. It contains some "getter" - methods like > > > > public int getObjectPendingFinalizationCount(); > > > > public MemoryUsage getHeapMemoryUsage(); > > > > Do you think we could add a method (or methods) for accessing the > > existing OOM counters > > > > ( for example, public OomCounters getOutOfMemoryCounters(); ) ? > > > > Best regards, Matthias > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Sep 21 09:26:43 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 21 Sep 2018 05:26:43 -0400 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> Message-ID: Looks good to me. For the javadoc 72 *

73 * If arguments contains addressing information. and 74 * only one connection will be accepted, the {@link #accept accept} method 75 * can be called immediately without calling this method. 76 * 77 * If the addressing information provided in arguments implies 78 * the auto detection this information might be updated with the address 79 * of the started listener. ? - you could add a

tag if you want to maintain the spacing in the generated javadoc. ? - I've seen other changesets migrating to {@code ..} from the older ... It would be good to include some negative testing. Not sure if it is already covered in other tests, e.g. ??? args1 = defaultArguments() ??? startListening(args1)?? // bound port updated ??? startListening(args1)?? // already listening On 9/20/18 10:59 PM, Daniil Titov wrote: > Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. > > When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However, the consequent call of startListening() methods with unspecified port number fails rather than starts a new listener on auto detected port. This happens since the original argument map passed to the startListening() methods is used as a key to store the mapping to the started listeners. > > The fix ensures that in cases when the port is auto detected the argument map is updated with the bound port number. > > Mach5 vmTestbase_nsk_jdi tests successfully passed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > Thanks! > --Daniil > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Sep 21 10:36:51 2018 From: jini.george at oracle.com (Jini George) Date: Fri, 21 Sep 2018 16:06:51 +0530 Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: References: Message-ID: Hi Fairoz, This looks good to me. One nit which got missed out in the original change also is that in saproc.cpp, the following comments 452 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later 477 /*ARGSUSED*/ would not be required anymore. And we would not need the wrapper to the callback routine fill_cframe_list() -- as in, we would need only one routine with the appropriate arguments passed. But you are free to ignore this since this was not done as a part of the original change. Thanks, Jini (Not a Reviewer). On 9/20/2018 7:06 PM, Fairoz Matte wrote: > Hi, > > Kindly review the backport of "JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core" to 8u > > Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 > > JDK9 changeset - http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 > > JDK9 review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-October/020543.html > > Thanks, > Fairoz > From gary.adams at oracle.com Fri Sep 21 12:18:44 2018 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 21 Sep 2018 08:18:44 -0400 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <10437553-2276-8b88-9189-493b4c5b4d89@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> <2d2838bf-5183-2b36-7b46-4044c18eccb6@oracle.com> <10437553-2276-8b88-9189-493b4c5b4d89@oracle.com> Message-ID: <5BA4E1A4.6000603@oracle.com> Patch attached. On 9/20/18, 8:17 PM, Chris Plummer wrote: > Ok, so you're just suggesting that findPrompt() should require that > the prompt be at the end of the line. In fact probably on a line by > itself. Keep in mind that we also have issues with async printing that > tends to result in the prompt appearing in the middle of some lines. > We have most of these situations understood and under control now, but > I'm guessing they still turn up in some places, and would cause > findPrompt() to fail. > > Chris > > On 9/20/18 4:06 PM, Alex Menkov wrote: >> To be detected the output line should ends with "Boolean[1] " >> >> So "Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will >> be instance of java.lang.Boolean[1] (id=706):" does not match. >> It seems to me that other bugs Gary is working have similar cases. >> >> --alex >> >> On 09/20/2018 15:27, Chris Plummer wrote: >>> The regex you give would still detect Boolean[1] as a prompt, which >>> we don't want. >>> >>> Chris >>> >>> On 9/20/18 3:22 PM, Alex Menkov wrote: >>>> May be it would be better to fix Jdb.receiveReplyFor to properly >>>> handle all replies like >>>> Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will be >>>> instance of java.lang.Boolean[1] (id=706): >>>> >>>> jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: >>>> "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" >>>> (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or >>>> test/jdk/com/sun/jdi/ShellScaffold.sh) >>>> AFAIR nsk/../Jdb does not use regexp, but I believe it can be >>>> updated to work the same way. >>>> >>>> --alex >>>> >>>> >>>> On 09/20/2018 14:50, Chris Plummer wrote: >>>>> This one is a little different than exclude001 in that we don't >>>>> control the name of the thread. We know (at least at the moment) >>>>> that it is called "main", but that could always change. In general >>>>> I'm fine with this fix, but if you have others like it, I'd >>>>> suggest putting the "main" thread name in single place, not in >>>>> each test that cares about it. >>>>> >>>>> Chris >>>>> >>>>> On 9/20/18 10:54 AM, Gary Adams wrote: >>>>>> The corrupted output has been identified due to the "Boolean[1]" >>>>>> being misrecognized as a compound prompt. >>>>>> >>>>>> The proposed fix waits for the correct prompt before >>>>>> advancing to the next command. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >>>>>> >>>>>> Testing is in progress. >>>>> >>>>> >>>>> >>> >>> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8208471.patch URL: From fairoz.matte at oracle.com Fri Sep 21 13:55:30 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 21 Sep 2018 06:55:30 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: References: Message-ID: <2ab73845-93b5-4cd0-9702-1b4bd2a1a3d8@default> Hi Jini, Thanks for the review. Thanks, Fairoz > -----Original Message----- > From: Jini George > Sent: Friday, September 21, 2018 4:07 PM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core > > Hi Fairoz, > > This looks good to me. One nit which got missed out in the original change > also is that in saproc.cpp, the following comments > > 452 > 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 > > 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later > 477 /*ARGSUSED*/ > > would not be required anymore. And we would not need the wrapper to the > callback routine fill_cframe_list() -- as in, we would need only one routine > with the appropriate arguments passed. But you are free to ignore this since > this was not done as a part of the original change. > > Thanks, > Jini (Not a Reviewer). > > > > On 9/20/2018 7:06 PM, Fairoz Matte wrote: > > Hi, > > > > Kindly review the backport of "JDK-8164383 : jhsdb dumps core on > > Solaris 12 when loading dumped core" to 8u > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 > > > > JDK9 changeset - > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 > > > > JDK9 review thread - > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-October > > /020543.html > > > > Thanks, > > Fairoz > > From jcbeyler at google.com Fri Sep 21 15:00:13 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 08:00:13 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: Message-ID: Hi all, Is anyone motivated on a Friday to review this ? :) It should be fairly straightforward :-) Thanks, Jc On Tue, Sep 18, 2018 at 12:07 PM JC Beyler wrote: > Hi all, > > Could I have a review for this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > Let me know what you think, > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Sep 21 15:19:19 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Sep 2018 15:19:19 +0000 Subject: OOM counters In-Reply-To: References: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> Message-ID: > > Sorry, when I said "we added" I meant "in our internal JDK at Google" :-); not the OpenJDK one. But basically, from what I can tell when I look at the code; when an OOM happens, > we get a callback and do some book-keeping in native land before returning and letting the JVM close up shop. > HI JC, that sounds interesting and in case it is better than what we have at the moment in OpenJDK , it is interesting for us too . From my understanding we have already some kind of callbacks in the present OpenJDK for handling the OOMs : * the XX flags ExitOnOutOfMemoryError and OnOutOfMemoryError= : this is in the hotspot code , however this is a bit limited because it limits you to exit, or call an external shell script/command via fork * JVMTI (haven?t looked into the details, but I think you would need to code a JVM agent ? not an option in some use cases) The use case our customers have and you asked about is more or less like what you describe in your first scenario . They check in some cycle for OOM , then do some tracing maybe cleanup and exit . For this , they can use the eventqueue of our SAP-internal JDK . Best regards, Matthias From: JC Beyler Sent: Freitag, 21. September 2018 16:59 To: Baesken, Matthias Cc: David Holmes ; serviceability-dev at openjdk.java.net Subject: Re: OOM counters Sorry, when I said "we added" I meant "in our internal JDK at Google" :-); not the OpenJDK one. But basically, from what I can tell when I look at the code; when an OOM happens, we get a callback and do some book-keeping in native land before returning and letting the JVM close up shop. I had plans of also finding out if there is interest in pushing this forward and upstream for the community so: anyone can chime in now and say: yes this would be interesting to have. Note: I'm not saying this is better than what you have; I just don't fully comprehend your use-case. An API to inspect those counters seems weird to me: when would you actually use it to see the counters are not 0? The only two cases I can see is that you either: - The OOM happened and you caught it via a catch, now you go and look at the counters in Java land before the JVM will close up shop and do something with that information; seems weird to be doing things at an OOM in Java land but why not :) - The OOM happened, you caught it via a catch; but your setup is such that you can survive an OOM and thus logging why an OOM happened is interesting; as the jobs keep surviving OOMs, you can actually track why OOMs happened But perhaps I'm missing something :), my knowledge and understanding of OOMs (and let us be honest of actual Java land) is fairly limited :-) Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Sep 21 15:32:21 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 21 Sep 2018 08:32:21 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> Message-ID: <2FC7DF1A-A627-4F9D-9FD7-E091C56481BA@oracle.com> Thank you, JC! Please review an updated version of the patch that addresses these issues. Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.03/ Best regards, Daniiil From: JC Beyler Date: Thursday, September 20, 2018 at 8:59 PM To: Cc: Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Hi Daniil, I noticed a few nits: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/supportsMultipleConnections/supportsmultipleconnections002.java.html ? -> You have two 2018 in the copyright http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketListeningConnector.java.udiff.html ?-> Both new methods have an empty line at the start, is that intended? ?-> updateArgumentMapIfRequired: you check the length > 0 but assume actually it is > 1 http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/GenericListeningConnector.java.udiff.html ? -> Same not sure we need the extra line Apart from that it looks good to me. Thanks, Jc On Thu, Sep 20, 2018 at 8:00 PM Daniil Titov wrote: Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However,? the consequent call of startListening() methods with unspecified port number fails rather than starts a new listener on auto detected port. This happens since the original argument map passed to the startListening() methods is used as a key to store the mapping to the started listeners. The fix ensures that in cases when the port is auto detected the argument map is updated with the bound port number. Mach5 vmTestbase_nsk_jdi tests successfully passed. Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ Thanks! --Daniil -- Thanks, Jc From jcbeyler at google.com Fri Sep 21 16:05:33 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 09:05:33 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <2FC7DF1A-A627-4F9D-9FD7-E091C56481BA@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <2FC7DF1A-A627-4F9D-9FD7-E091C56481BA@oracle.com> Message-ID: Looks good to me Daniil (not a reviewer though), Thanks! Jc On Fri, Sep 21, 2018 at 8:32 AM Daniil Titov wrote: > Thank you, JC! > > Please review an updated version of the patch that addresses these issues. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.03/ > > Best regards, > Daniiil > > From: JC Beyler > Date: Thursday, September 20, 2018 at 8:59 PM > To: > Cc: > Subject: Re: RFR 8163083: SocketListeningConnector does not allow > invocations with port 0 > > Hi Daniil, > > I noticed a few nits: > > > http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/supportsMultipleConnections/supportsmultipleconnections002.java.html > > -> You have two 2018 in the copyright > > > http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketListeningConnector.java.udiff.html > > -> Both new methods have an empty line at the start, is that intended? > -> updateArgumentMapIfRequired: you check the length > 0 but assume > actually it is > 1 > > > http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/GenericListeningConnector.java.udiff.html > -> Same not sure we need the extra line > > Apart from that it looks good to me. > > Thanks, > Jc > > On Thu, Sep 20, 2018 at 8:00 PM Daniil Titov daniil.x.titov at oracle.com> wrote: > Please review the change that fixes the issue in > com.sun.tools.jdi.SocketListenerConnector.startListening() method. > > When the argument map passed to startListening() methods has the port > number unspecified or set to zero the port is auto detected. However, the > consequent call of startListening() methods with unspecified port number > fails rather than starts a new listener on auto detected port. This happens > since the original argument map passed to the startListening() methods is > used as a key to store the mapping to the started listeners. > > The fix ensures that in cases when the port is auto detected the argument > map is updated with the bound port number. > > Mach5 vmTestbase_nsk_jdi tests successfully passed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > Thanks! > --Daniil > > > > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Sep 21 16:12:42 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Sep 2018 09:12:42 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <5BA4E1A4.6000603@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> <2d2838bf-5183-2b36-7b46-4044c18eccb6@oracle.com> <10437553-2276-8b88-9189-493b4c5b4d89@oracle.com> <5BA4E1A4.6000603@oracle.com> Message-ID: <0936cd16-0488-bf75-6383-8eb62bd5733e@oracle.com> I don't think Alex actually gave a thumbs up for this change yet. He just offered a suggestion for an alternate way to fix. Chris On 9/21/18 5:18 AM, Gary Adams wrote: > Patch attached. > > > On 9/20/18, 8:17 PM, Chris Plummer wrote: >> Ok, so you're just suggesting that findPrompt() should require that >> the prompt be at the end of the line. In fact probably on a line by >> itself. Keep in mind that we also have issues with async printing >> that tends to result in the prompt appearing in the middle of some >> lines. We have most of these situations understood and under control >> now, but I'm guessing they still turn up in some places, and would >> cause findPrompt() to fail. >> >> Chris >> >> On 9/20/18 4:06 PM, Alex Menkov wrote: >>> To be detected the output line should ends with "Boolean[1] " >>> >>> So "Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will >>> be instance of java.lang.Boolean[1] (id=706):" does not match. >>> It seems to me that other bugs Gary is working have similar cases. >>> >>> --alex >>> >>> On 09/20/2018 15:27, Chris Plummer wrote: >>>> The regex you give would still detect Boolean[1] as a prompt, which >>>> we don't want. >>>> >>>> Chris >>>> >>>> On 9/20/18 3:22 PM, Alex Menkov wrote: >>>>> May be it would be better to fix Jdb.receiveReplyFor to properly >>>>> handle all replies like >>>>> Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will >>>>> be instance of java.lang.Boolean[1] (id=706): >>>>> >>>>> jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: >>>>> "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" >>>>> (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or >>>>> test/jdk/com/sun/jdi/ShellScaffold.sh) >>>>> AFAIR nsk/../Jdb does not use regexp, but I believe it can be >>>>> updated to work the same way. >>>>> >>>>> --alex >>>>> >>>>> >>>>> On 09/20/2018 14:50, Chris Plummer wrote: >>>>>> This one is a little different than exclude001 in that we don't >>>>>> control the name of the thread. We know (at least at the moment) >>>>>> that it is called "main", but that could always change. In >>>>>> general I'm fine with this fix, but if you have others like it, >>>>>> I'd suggest putting the "main" thread name in single place, not >>>>>> in each test that cares about it. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/20/18 10:54 AM, Gary Adams wrote: >>>>>>> The corrupted output has been identified due to the "Boolean[1]" >>>>>>> being misrecognized as a compound prompt. >>>>>>> >>>>>>> The proposed fix waits for the correct prompt before >>>>>>> advancing to the next command. >>>>>>> >>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >>>>>>> >>>>>>> Testing is in progress. >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> > From chris.plummer at oracle.com Fri Sep 21 17:16:20 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Sep 2018 10:16:20 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 21 17:55:26 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 10:55:26 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: Message-ID: Hi Chris, I hesitated to be honest and then thought that debug_str was better as you would clearly see that it is a multi-lilne string and what parameters are what. But I'll take your preference (it's relatively the same for me). Quick question though: Do you have a preference between: NSK_COMPLAIN6( "TEST FAILED: %s field \"%s\" has\n" "\tsignature: \"%s\"\n" "\tgeneric signature: \"%s\"\n\n" "\tExpected: \"%s\"\n" "\t\t\"%s\"\n\n", (instance==0)?"instance":"static", fld_sig[idx][0], sign, (gen_sign==NULL)?"NULL":gen_sign, fld_sig[idx][2], fld_sig[idx][3]); or: NSK_COMPLAIN6( "TEST FAILED: %s field \"%s\" has\n\tsignature: \"%s\"\n" "\tgeneric signature: \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", (instance==0)?"instance":"static", fld_sig[idx][0], sign, (gen_sign==NULL)?"NULL":gen_sign, fld_sig[idx][2], fld_sig[idx][3]); I think I like the first because you can clearly see what we want to be printed out; but for code vertical compression, the second is better. What do you think? Thanks! Jc On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer wrote: > Hi JC, > > I didn't realize you intended to move all the strings into a "const char*" > first. Seems unnecessary, and I think not as easy to read: > > 138 const char* debug_str = > 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received for\n" > 140 "\t a primitive class/array of primitive types with the > signature \"%s\"\n"; > 141 NSK_COMPLAIN1(debug_str, sig); > > vs > > 138 NSK_COMPLAIN1("TEST FAILED: JVMTI_EVENT_CLASS_LOAD event > received for\n" > 139 "\t a primitive class/array of primitive types > with the signature \"%s\"\n", > 140 sig); > > or > > 138 NSK_COMPLAIN1( > 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received for\n" > 140 "\t a primitive class/array of primitive types with the > signature \"%s\"\n", > 141 sig); > > thanks, > > Chris > > On 9/21/18 8:00 AM, JC Beyler wrote: > > Hi all, > > Is anyone motivated on a Friday to review this ? :) > > It should be fairly straightforward :-) > > Thanks, > Jc > > On Tue, Sep 18, 2018 at 12:07 PM JC Beyler wrote: > >> Hi all, >> >> Could I have a review for this webrev: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >> >> Let me know what you think, >> Jc >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Sep 21 17:59:28 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Sep 2018 10:59:28 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: Message-ID: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 21 20:05:02 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 13:05:02 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> Message-ID: Hi Chris, Sounds good to me; here it is: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 I admit I strived to stay consistent and always started a new line for the multi-line argument even if the string was not too long; it's a question of style I believe but it felt more readable to me. I'll happily change whatever anyone prefers. This has passed the vmTestbase tests I changed but due to the shared changes, I've launched a full vmTestbase testing now. Let me know what you think, Jc On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer wrote: > On 9/21/18 10:55 AM, JC Beyler wrote: > > Hi Chris, > > I hesitated to be honest and then thought that debug_str was better as you > would clearly see that it is a multi-lilne string and what parameters are > what. But I'll take your preference (it's relatively the same for me). > Quick question though: > > Do you have a preference between: > > NSK_COMPLAIN6( > "TEST FAILED: %s field \"%s\" has\n" > "\tsignature: \"%s\"\n" > "\tgeneric signature: \"%s\"\n\n" > "\tExpected: \"%s\"\n" > "\t\t\"%s\"\n\n", > (instance==0)?"instance":"static", > fld_sig[idx][0], > sign, (gen_sign==NULL)?"NULL":gen_sign, > fld_sig[idx][2], fld_sig[idx][3]); > > or: > > NSK_COMPLAIN6( > "TEST FAILED: %s field \"%s\" has\n\tsignature: \"%s\"\n" > "\tgeneric signature: \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", > (instance==0)?"instance":"static", > fld_sig[idx][0], > sign, (gen_sign==NULL)?"NULL":gen_sign, > fld_sig[idx][2], fld_sig[idx][3]); > > I think I like the first because you can clearly see what we want to be printed out; but for code vertical > > compression, the second is better. What do you think? > > I also prefer the first one. > > thanks, > > Chris > > Thanks! > > Jc > > > On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer > wrote: > >> Hi JC, >> >> I didn't realize you intended to move all the strings into a "const >> char*" first. Seems unnecessary, and I think not as easy to read: >> >> 138 const char* debug_str = >> 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received >> for\n" >> 140 "\t a primitive class/array of primitive types with the >> signature \"%s\"\n"; >> 141 NSK_COMPLAIN1(debug_str, sig); >> >> vs >> >> 138 NSK_COMPLAIN1("TEST FAILED: JVMTI_EVENT_CLASS_LOAD event >> received for\n" >> 139 "\t a primitive class/array of primitive types >> with the signature \"%s\"\n", >> 140 sig); >> >> or >> >> 138 NSK_COMPLAIN1( >> 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received >> for\n" >> 140 "\t a primitive class/array of primitive types with the >> signature \"%s\"\n", >> 141 sig); >> >> thanks, >> >> Chris >> >> On 9/21/18 8:00 AM, JC Beyler wrote: >> >> Hi all, >> >> Is anyone motivated on a Friday to review this ? :) >> >> It should be fairly straightforward :-) >> >> Thanks, >> Jc >> >> On Tue, Sep 18, 2018 at 12:07 PM JC Beyler wrote: >> >>> Hi all, >>> >>> Could I have a review for this webrev: >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >>> >>> Let me know what you think, >>> Jc >>> >> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Sep 21 20:46:44 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Sep 2018 13:46:44 -0700 Subject: RFR(XS): JDK-8210987: Extra newlines on Windows when running nsk jdb tests Message-ID: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> Hi, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8210987 http://cr.openjdk.java.net/~cjplummer/8210987/webrev.00/ Here's an example of some "before" output on windows: > Sending command: cont > > reply[0]: > > reply[1]: > Method entered: "thread=MyThread-1", java.util.Locale.getDefault(), line=910 bci=0 > reply[2]: > > reply[3]: > MyThread-1[1] And the same output after the fix: > Sending command: cont > reply[0]: > > reply[1]: Method entered: "thread=MyThread-1", java.util.Locale.getDefault(), line=910 bci=0 > reply[2]: > reply[3]: MyThread-1[1] And this also matches the output we've been seeing on the unix platforms. thanks, Chris From chris.plummer at oracle.com Fri Sep 21 21:07:36 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Sep 2018 14:07:36 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> Message-ID: <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 21 21:19:07 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 14:19:07 -0700 Subject: RFR(XS): JDK-8210987: Extra newlines on Windows when running nsk jdb tests In-Reply-To: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> References: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> Message-ID: Hi Chris, Looks good to me! Thanks, Jc On Fri, Sep 21, 2018 at 1:47 PM Chris Plummer wrote: > Hi, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8210987 > http://cr.openjdk.java.net/~cjplummer/8210987/webrev.00/ > > Here's an example of some "before" output on windows: > > > Sending command: cont > > > > reply[0]: > > > reply[1]: > > Method entered: "thread=MyThread-1", java.util.Locale.getDefault(), > line=910 bci=0 > > reply[2]: > > > > reply[3]: > > MyThread-1[1] > > And the same output after the fix: > > > Sending command: cont > > reply[0]: > > > reply[1]: Method entered: "thread=MyThread-1", > java.util.Locale.getDefault(), line=910 bci=0 > > reply[2]: > > reply[3]: MyThread-1[1] > > And this also matches the output we've been seeing on the unix platforms. > > thanks, > > Chris > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 21 21:29:55 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 14:29:55 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> Message-ID: Hi Chris, Done here: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 Anything else? and anybody else motivated to look? Thanks again! Jc On Fri, Sep 21, 2018 at 2:07 PM Chris Plummer wrote: > Hi JC, > > Overall looks good. Just a couple minor edits needed: > > In nativemethbind003.cpp: > > 158 NSK_DISPLAY1("Inside the registerNative()\nFinding class \"%s\" > ...\n", CLASS_SIG); > > This was two lines and you made it one with a \n in the middle of the > string. > > In ap12t001.cpp: > > 69 NSK_COMPLAIN2( > 70 "Received unexpected number of ObjectFree events: %d\n" > 71 "\texpected number: %d", > 72 obj_free, EXP_OBJ_FREE); > > There's no \n at the end of this output (and there never was). Normally > NSK_COMPLAIN is always used with a terminating \n. > > thanks, > > Chris > > > On 9/21/18 1:05 PM, JC Beyler wrote: > > Hi Chris, > > Sounds good to me; here it is: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > I admit I strived to stay consistent and always started a new line for the > multi-line argument even if the string was not too long; it's a question of > style I believe but it felt more readable to me. I'll happily change > whatever anyone prefers. > > This has passed the vmTestbase tests I changed but due to the shared > changes, I've launched a full vmTestbase testing now. > > Let me know what you think, > Jc > > On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer > wrote: > >> On 9/21/18 10:55 AM, JC Beyler wrote: >> >> Hi Chris, >> >> I hesitated to be honest and then thought that debug_str was better as >> you would clearly see that it is a multi-lilne string and what parameters >> are what. But I'll take your preference (it's relatively the same for me). >> Quick question though: >> >> Do you have a preference between: >> >> NSK_COMPLAIN6( >> "TEST FAILED: %s field \"%s\" has\n" >> "\tsignature: \"%s\"\n" >> "\tgeneric signature: \"%s\"\n\n" >> "\tExpected: \"%s\"\n" >> "\t\t\"%s\"\n\n", >> (instance==0)?"instance":"static", >> fld_sig[idx][0], >> sign, (gen_sign==NULL)?"NULL":gen_sign, >> fld_sig[idx][2], fld_sig[idx][3]); >> >> or: >> >> NSK_COMPLAIN6( >> "TEST FAILED: %s field \"%s\" has\n\tsignature: \"%s\"\n" >> "\tgeneric signature: \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", >> (instance==0)?"instance":"static", >> fld_sig[idx][0], >> sign, (gen_sign==NULL)?"NULL":gen_sign, >> fld_sig[idx][2], fld_sig[idx][3]); >> >> I think I like the first because you can clearly see what we want to be printed out; but for code vertical >> >> compression, the second is better. What do you think? >> >> I also prefer the first one. >> >> thanks, >> >> Chris >> >> Thanks! >> >> Jc >> >> >> On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer >> wrote: >> >>> Hi JC, >>> >>> I didn't realize you intended to move all the strings into a "const >>> char*" first. Seems unnecessary, and I think not as easy to read: >>> >>> 138 const char* debug_str = >>> 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received >>> for\n" >>> 140 "\t a primitive class/array of primitive types with the >>> signature \"%s\"\n"; >>> 141 NSK_COMPLAIN1(debug_str, sig); >>> >>> vs >>> >>> 138 NSK_COMPLAIN1("TEST FAILED: JVMTI_EVENT_CLASS_LOAD event >>> received for\n" >>> 139 "\t a primitive class/array of primitive >>> types with the signature \"%s\"\n", >>> 140 sig); >>> >>> or >>> >>> 138 NSK_COMPLAIN1( >>> 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD event received >>> for\n" >>> 140 "\t a primitive class/array of primitive types with >>> the signature \"%s\"\n", >>> 141 sig); >>> >>> thanks, >>> >>> Chris >>> >>> On 9/21/18 8:00 AM, JC Beyler wrote: >>> >>> Hi all, >>> >>> Is anyone motivated on a Friday to review this ? :) >>> >>> It should be fairly straightforward :-) >>> >>> Thanks, >>> Jc >>> >>> On Tue, Sep 18, 2018 at 12:07 PM JC Beyler wrote: >>> >>>> Hi all, >>>> >>>> Could I have a review for this webrev: >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >>>> >>>> Let me know what you think, >>>> Jc >>>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Sep 21 21:56:01 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Sep 2018 14:56:01 -0700 Subject: RFR: JDK-8208471: nsk/jdb/unwatch/unwatch002/unwatch002.java fails with "Prompt is not received during 300200 milliseconds" In-Reply-To: <0936cd16-0488-bf75-6383-8eb62bd5733e@oracle.com> References: <5BA3DEEA.9070604@oracle.com> <4255e8fc-ca3d-0d90-3973-0be70467a957@oracle.com> <87061b3a-4173-45aa-1502-cf84a3277bee@oracle.com> <952679d8-fd14-db98-7f22-b76436e42162@oracle.com> <2d2838bf-5183-2b36-7b46-4044c18eccb6@oracle.com> <10437553-2276-8b88-9189-493b4c5b4d89@oracle.com> <5BA4E1A4.6000603@oracle.com> <0936cd16-0488-bf75-6383-8eb62bd5733e@oracle.com> Message-ID: <03fa7b41-44fc-1a5b-5bc1-474ed2ade868@oracle.com> Thanks, Chris, Looked at the issues and nsk jdb stuff again - may be you are right and fixing nsk jdb code we can get a bunch of new test issues. So ok, lets make local fixes for the known issues for now. LGTM. --alex On 09/21/2018 09:12, Chris Plummer wrote: > I don't think Alex actually gave a thumbs up for this change yet. He > just offered a suggestion for an alternate way to fix. > > Chris > > On 9/21/18 5:18 AM, Gary Adams wrote: >> Patch attached. >> >> >> On 9/20/18, 8:17 PM, Chris Plummer wrote: >>> Ok, so you're just suggesting that findPrompt() should require that >>> the prompt be at the end of the line. In fact probably on a line by >>> itself. Keep in mind that we also have issues with async printing >>> that tends to result in the prompt appearing in the middle of some >>> lines. We have most of these situations understood and under control >>> now, but I'm guessing they still turn up in some places, and would >>> cause findPrompt() to fail. >>> >>> Chris >>> >>> On 9/20/18 4:06 PM, Alex Menkov wrote: >>>> To be detected the output line should ends with "Boolean[1] " >>>> >>>> So "Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will >>>> be instance of java.lang.Boolean[1] (id=706):" does not match. >>>> It seems to me that other bugs Gary is working have similar cases. >>>> >>>> --alex >>>> >>>> On 09/20/2018 15:27, Chris Plummer wrote: >>>>> The regex you give would still detect Boolean[1] as a prompt, which >>>>> we don't want. >>>>> >>>>> Chris >>>>> >>>>> On 9/20/18 3:22 PM, Alex Menkov wrote: >>>>>> May be it would be better to fix Jdb.receiveReplyFor to properly >>>>>> handle all replies like >>>>>> Field (nsk.jdb.unwatch.unwatch002.unwatch002a.FS1) is null, will >>>>>> be instance of java.lang.Boolean[1] (id=706): >>>>>> >>>>>> jdk/com/sun/jdi tests use the following regexp to detect jdb prompt: >>>>>> "[a-zA-Z0-9_-][a-zA-Z0-9_-]*\[[1-9][0-9]*\] [ >]*$" >>>>>> (see test/jdk/com/sun/jdi/lib/jdb/Jdb.java or >>>>>> test/jdk/com/sun/jdi/ShellScaffold.sh) >>>>>> AFAIR nsk/../Jdb does not use regexp, but I believe it can be >>>>>> updated to work the same way. >>>>>> >>>>>> --alex >>>>>> >>>>>> >>>>>> On 09/20/2018 14:50, Chris Plummer wrote: >>>>>>> This one is a little different than exclude001 in that we don't >>>>>>> control the name of the thread. We know (at least at the moment) >>>>>>> that it is called "main", but that could always change. In >>>>>>> general I'm fine with this fix, but if you have others like it, >>>>>>> I'd suggest putting the "main" thread name in single place, not >>>>>>> in each test that cares about it. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/20/18 10:54 AM, Gary Adams wrote: >>>>>>>> The corrupted output has been identified due to the "Boolean[1]" >>>>>>>> being misrecognized as a compound prompt. >>>>>>>> >>>>>>>> The proposed fix waits for the correct prompt before >>>>>>>> advancing to the next command. >>>>>>>> >>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208471/webrev/ >>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208471 >>>>>>>> >>>>>>>> Testing is in progress. >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> > > From alexey.menkov at oracle.com Fri Sep 21 21:56:36 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Sep 2018 14:56:36 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: References: <5BA3DFFE.5090201@oracle.com> Message-ID: <9bb608eb-dc56-6c44-7997-3091aa57b6a2@oracle.com> +1 --alex On 09/20/2018 14:47, Chris Plummer wrote: > Looks good. Still not bullet proof, but I'm not sure it's possible to > write tests like this in a way that will work no matter what output is > produced by the method enter/exit events. > > Chris > > On 9/20/18 10:59 AM, Gary Adams wrote: >> The test failure has been identified due to the "int[2]" >> being misrecognized as a compound prompt.? This caused a cont >> command to be sent prematurely. >> >> The proposed fix waits for the correct prompt before >> advancing to the next command. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >> >> Testing is in progress. > > > From david.holmes at oracle.com Fri Sep 21 21:57:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Sep 2018 17:57:58 -0400 Subject: RFR(XS): JDK-8210987: Extra newlines on Windows when running nsk jdb tests In-Reply-To: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> References: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> Message-ID: Looks fine. Thanks, David On 21/09/2018 4:46 PM, Chris Plummer wrote: > Hi, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8210987 > http://cr.openjdk.java.net/~cjplummer/8210987/webrev.00/ > > Here's an example of some "before" output on windows: > >> Sending command: cont >> >> reply[0]: > >> reply[1]: >> Method entered: "thread=MyThread-1", java.util.Locale.getDefault(), >> line=910 bci=0 >> reply[2]: >> >> reply[3]: >> MyThread-1[1] > > And the same output after the fix: > >> Sending command: cont >> reply[0]: > >> reply[1]: Method entered: "thread=MyThread-1", >> java.util.Locale.getDefault(), line=910 bci=0 >> reply[2]: >> reply[3]: MyThread-1[1] > > And this also matches the output we've been seeing on the unix platforms. > > thanks, > > Chris > From chris.plummer at oracle.com Fri Sep 21 22:09:14 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 21 Sep 2018 15:09:14 -0700 Subject: RFR(XS): JDK-8210987: Extra newlines on Windows when running nsk jdb tests In-Reply-To: References: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> Message-ID: Thanks David and JC! On 9/21/18 2:57 PM, David Holmes wrote: > Looks fine. > > Thanks, > David > > On 21/09/2018 4:46 PM, Chris Plummer wrote: >> Hi, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8210987 >> http://cr.openjdk.java.net/~cjplummer/8210987/webrev.00/ >> >> Here's an example of some "before" output on windows: >> >>> Sending command: cont >>> >>> reply[0]: > >>> reply[1]: >>> Method entered: "thread=MyThread-1", java.util.Locale.getDefault(), >>> line=910 bci=0 >>> reply[2]: >>> >>> reply[3]: >>> MyThread-1[1] >> >> And the same output after the fix: >> >>> Sending command: cont >>> reply[0]: > >>> reply[1]: Method entered: "thread=MyThread-1", >>> java.util.Locale.getDefault(), line=910 bci=0 >>> reply[2]: >>> reply[3]: MyThread-1[1] >> >> And this also matches the output we've been seeing on the unix >> platforms. >> >> thanks, >> >> Chris >> From alexey.menkov at oracle.com Fri Sep 21 22:44:15 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Sep 2018 15:44:15 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> Message-ID: <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> Hi Jc, overall looks good (no changes in the logging) except test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp : - if ((strcmp(name, expMeth) == 0) && - (strcmp(sig, expSig) == 0)) { - NSK_DISPLAY4("===== %s event received for the tested method:\n\ -\tID=0x%p name=\"%s\" signature=\"%s\"\n", + if ((strcmp(name, expMeth) == 0) && (strcmp(sig, expSig) == 0)) { + NSK_DISPLAY4( + "%s event received for the tested method:\n" + "\tID=0x%p name=\"%s\" signature=\"%s\"\n", "===== " is dropped from the beginning of the line I don't know if this is important. --alex On 09/21/2018 14:29, JC Beyler wrote: > Hi Chris, > > Done here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > Anything else? and anybody else motivated to look? > > Thanks again! > Jc > > On Fri, Sep 21, 2018 at 2:07 PM Chris Plummer > wrote: > > Hi JC, > > Overall looks good. Just a couple minor edits needed: > > In nativemethbind003.cpp: > > ?158???? NSK_DISPLAY1("Inside the registerNative()\nFinding class > \"%s\" ...\n", CLASS_SIG); > > This was two lines and you made it one with a \n in the middle of > the string. > > In ap12t001.cpp: > > ? 69???????? NSK_COMPLAIN2( > ? 70???????????? "Received unexpected number of ObjectFree events: > %d\n" > ? 71???????????? "\texpected number: %d", > ? 72???????????? obj_free, EXP_OBJ_FREE); > > There's no \n at the end of this output (and there never was). > Normally NSK_COMPLAIN is always used with a terminating \n. > > thanks, > > Chris > > > On 9/21/18 1:05 PM, JC Beyler wrote: >> Hi Chris, >> >> Sounds good to me; here it is: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >> >> I admit I strived to stay consistent and always started a new line >> for the multi-line argument even if the string was not too long; >> it's a question of style I believe but it felt more readable to >> me. I'll happily change whatever anyone prefers. >> >> This has passed the vmTestbase tests I changed but due to the >> shared changes, I've launched a full vmTestbase testing now. >> >> Let me know what you think, >> Jc >> >> On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer >> > wrote: >> >> On 9/21/18 10:55 AM, JC Beyler wrote: >>> Hi Chris, >>> >>> I hesitated to be honest and then thought that debug_str was >>> better as you would clearly see that it is a multi-lilne >>> string and what parameters are what. But I'll take your >>> preference (it's relatively the same for me). Quick question >>> though: >>> >>> Do you have a preference between: >>> NSK_COMPLAIN6( >>> "TEST FAILED: %s field \"%s\" has\n" >>> "\tsignature: \"%s\"\n" >>> "\tgeneric signature: \"%s\"\n\n" >>> "\tExpected: \"%s\"\n" >>> "\t\t\"%s\"\n\n", >>> (instance==0)?"instance":"static", >>> fld_sig[idx][0], >>> sign, (gen_sign==NULL)?"NULL":gen_sign, >>> fld_sig[idx][2], fld_sig[idx][3]); >>> or: >>> NSK_COMPLAIN6( >>> "TEST FAILED: %s field \"%s\" has\n\tsignature: \"%s\"\n" >>> "\tgeneric signature: \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", >>> (instance==0)?"instance":"static", >>> fld_sig[idx][0], >>> sign, (gen_sign==NULL)?"NULL":gen_sign, >>> fld_sig[idx][2], fld_sig[idx][3]); >>> I think I like the first because you can clearly see what we want to be printed out; but for code vertical >>> compression, the second is better. What do you think? >> I also prefer the first one. >> >> thanks, >> >> Chris >>> Thanks! >>> Jc >>> >>> On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer >>> > >>> wrote: >>> >>> Hi JC, >>> >>> I didn't realize you intended to move all the strings >>> into a "const char*" first. Seems unnecessary, and I >>> think not as easy to read: >>> >>> ?138???????? const char* debug_str = >>> ?139???????????? "TEST FAILED: JVMTI_EVENT_CLASS_LOAD >>> event received for\n" >>> ?140???????????? "\t a primitive class/array of primitive >>> types with the signature \"%s\"\n"; >>> ?141???????? NSK_COMPLAIN1(debug_str, sig); >>> >>> vs >>> >>> ?138???????? NSK_COMPLAIN1("TEST FAILED: >>> JVMTI_EVENT_CLASS_LOAD event received for\n" >>> ?139?????????????????????? "\t a primitive class/array of >>> primitive types with the signature \"%s\"\n", >>> ?140?????????????????????? sig); >>> >>> or >>> >>> ?138???????? NSK_COMPLAIN1( >>> ?139???????????? "TEST FAILED: JVMTI_EVENT_CLASS_LOAD >>> event received for\n" >>> 140 ??????????? "\t a primitive class/array of primitive >>> types with the signature \"%s\"\n", >>> 141 ??????????? sig); >>> >>> thanks, >>> >>> Chris >>> >>> On 9/21/18 8:00 AM, JC Beyler wrote: >>>> Hi all, >>>> >>>> Is anyone motivated on a Friday to review this ? :) >>>> >>>> It should be fairly straightforward :-) >>>> >>>> Thanks, >>>> Jc >>>> >>>> On Tue, Sep 18, 2018 at 12:07 PM JC Beyler >>>> > wrote: >>>> >>>> Hi all, >>>> >>>> Could I have a review for this webrev: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >>>> >>>> Let me know what you think, >>>> Jc >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> >> >> >> -- >> >> Thanks, >> Jc > > > > > -- > > Thanks, > Jc From alexey.menkov at oracle.com Fri Sep 21 22:44:57 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Sep 2018 15:44:57 -0700 Subject: RFR(XS): JDK-8210987: Extra newlines on Windows when running nsk jdb tests In-Reply-To: References: <177c847a-ed91-f862-f22d-84cb9c9376d9@oracle.com> Message-ID: <022e6583-ab9c-9012-3bd9-9d9c492bf352@oracle.com> +1 --alex On 09/21/2018 14:19, JC Beyler wrote: > Hi Chris, > > Looks good to me! > > Thanks, > Jc > > On Fri, Sep 21, 2018 at 1:47 PM Chris Plummer > wrote: > > Hi, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8210987 > http://cr.openjdk.java.net/~cjplummer/8210987/webrev.00/ > > > Here's an example of some "before" output on windows: > > > Sending command: cont > > > > reply[0]: > > > reply[1]: > > Method entered: "thread=MyThread-1", > java.util.Locale.getDefault(), line=910 bci=0 > > reply[2]: > > > > reply[3]: > > MyThread-1[1] > > And the same output after the fix: > > > Sending command: cont > > reply[0]: > > > reply[1]: Method entered: "thread=MyThread-1", > java.util.Locale.getDefault(), line=910 bci=0 > > reply[2]: > > reply[3]: MyThread-1[1] > > And this also matches the output we've been seeing on the unix > platforms. > > thanks, > > Chris > > > > -- > > Thanks, > Jc From alexey.menkov at oracle.com Fri Sep 21 22:59:46 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Sep 2018 15:59:46 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> Message-ID: <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> One more note: please add "@Override" annotation to the SocketListeningConnector.updateArgumentMapIfRequired --alex On 09/21/2018 02:26, gary.adams at oracle.com wrote: > Looks good to me. > > For the javadoc > > 72 *

> 73 * If arguments contains addressing information. and > 74 * only one connection will be accepted, the {@link #accept accept} method > 75 * can be called immediately without calling this method. > 76 * > 77 * If the addressing information provided in arguments > implies > 78 * the auto detection this information might be updated with the address > 79 * of the started listener. > > ? - you could add a

tag if you want to maintain the spacing in the > generated javadoc. > ? - I've seen other changesets migrating to {@code ..} from the older > ... > > It would be good to include some negative testing. > Not sure if it is already covered in other tests, e.g. > > ??? args1 = defaultArguments() > ??? startListening(args1)?? // bound port updated > ??? startListening(args1)?? // already listening > > > On 9/20/18 10:59 PM, Daniil Titov wrote: >> Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. >> >> When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However, the consequent call of startListening() methods with unspecified port number fails rather than starts a new listener on auto detected port. This happens since the original argument map passed to the startListening() methods is used as a key to store the mapping to the started listeners. >> >> The fix ensures that in cases when the port is auto detected the argument map is updated with the bound port number. >> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >> >> Thanks! >> --Daniil >> >> >> > From jcbeyler at google.com Sat Sep 22 00:06:45 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Sep 2018 17:06:45 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> Message-ID: Hi Alex, Good catch, it was not done on purpose but now fixed: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 Let me know if this works for you and thanks for the review, Jc On Fri, Sep 21, 2018 at 3:44 PM Alex Menkov wrote: > Hi Jc, > > overall looks good (no changes in the logging) > except > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp > > : > - if ((strcmp(name, expMeth) == 0) && > - (strcmp(sig, expSig) == 0)) { > - NSK_DISPLAY4("===== %s event received for the tested method:\n\ > -\tID=0x%p name=\"%s\" signature=\"%s\"\n", > + if ((strcmp(name, expMeth) == 0) && (strcmp(sig, expSig) == 0)) { > + NSK_DISPLAY4( > + "%s event received for the tested method:\n" > + "\tID=0x%p name=\"%s\" signature=\"%s\"\n", > > "===== " is dropped from the beginning of the line > I don't know if this is important. > > --alex > > > On 09/21/2018 14:29, JC Beyler wrote: > > Hi Chris, > > > > Done here: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.02/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > > > Anything else? and anybody else motivated to look? > > > > Thanks again! > > Jc > > > > On Fri, Sep 21, 2018 at 2:07 PM Chris Plummer > > wrote: > > > > Hi JC, > > > > Overall looks good. Just a couple minor edits needed: > > > > In nativemethbind003.cpp: > > > > 158 NSK_DISPLAY1("Inside the registerNative()\nFinding class > > \"%s\" ...\n", CLASS_SIG); > > > > This was two lines and you made it one with a \n in the middle of > > the string. > > > > In ap12t001.cpp: > > > > 69 NSK_COMPLAIN2( > > 70 "Received unexpected number of ObjectFree events: > > %d\n" > > 71 "\texpected number: %d", > > 72 obj_free, EXP_OBJ_FREE); > > > > There's no \n at the end of this output (and there never was). > > Normally NSK_COMPLAIN is always used with a terminating \n. > > > > thanks, > > > > Chris > > > > > > On 9/21/18 1:05 PM, JC Beyler wrote: > >> Hi Chris, > >> > >> Sounds good to me; here it is: > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > >> > >> I admit I strived to stay consistent and always started a new line > >> for the multi-line argument even if the string was not too long; > >> it's a question of style I believe but it felt more readable to > >> me. I'll happily change whatever anyone prefers. > >> > >> This has passed the vmTestbase tests I changed but due to the > >> shared changes, I've launched a full vmTestbase testing now. > >> > >> Let me know what you think, > >> Jc > >> > >> On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer > >> > wrote: > >> > >> On 9/21/18 10:55 AM, JC Beyler wrote: > >>> Hi Chris, > >>> > >>> I hesitated to be honest and then thought that debug_str was > >>> better as you would clearly see that it is a multi-lilne > >>> string and what parameters are what. But I'll take your > >>> preference (it's relatively the same for me). Quick question > >>> though: > >>> > >>> Do you have a preference between: > >>> NSK_COMPLAIN6( > >>> "TEST FAILED: %s field \"%s\" has\n" > >>> "\tsignature: \"%s\"\n" > >>> "\tgeneric signature: \"%s\"\n\n" > >>> "\tExpected: \"%s\"\n" > >>> "\t\t\"%s\"\n\n", > >>> (instance==0)?"instance":"static", > >>> fld_sig[idx][0], > >>> sign, (gen_sign==NULL)?"NULL":gen_sign, > >>> fld_sig[idx][2], fld_sig[idx][3]); > >>> or: > >>> NSK_COMPLAIN6( > >>> "TEST FAILED: %s field \"%s\" > has\n\tsignature: \"%s\"\n" > >>> "\tgeneric signature: \"%s\"\n\n\tExpected: > \"%s\"\n\t\t\"%s\"\n\n", > >>> (instance==0)?"instance":"static", > >>> fld_sig[idx][0], > >>> sign, (gen_sign==NULL)?"NULL":gen_sign, > >>> fld_sig[idx][2], fld_sig[idx][3]); > >>> I think I like the first because you can clearly see what we > want to be printed out; but for code vertical > >>> compression, the second is better. What do you think? > >> I also prefer the first one. > >> > >> thanks, > >> > >> Chris > >>> Thanks! > >>> Jc > >>> > >>> On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer > >>> > > >>> wrote: > >>> > >>> Hi JC, > >>> > >>> I didn't realize you intended to move all the strings > >>> into a "const char*" first. Seems unnecessary, and I > >>> think not as easy to read: > >>> > >>> 138 const char* debug_str = > >>> 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD > >>> event received for\n" > >>> 140 "\t a primitive class/array of primitive > >>> types with the signature \"%s\"\n"; > >>> 141 NSK_COMPLAIN1(debug_str, sig); > >>> > >>> vs > >>> > >>> 138 NSK_COMPLAIN1("TEST FAILED: > >>> JVMTI_EVENT_CLASS_LOAD event received for\n" > >>> 139 "\t a primitive class/array of > >>> primitive types with the signature \"%s\"\n", > >>> 140 sig); > >>> > >>> or > >>> > >>> 138 NSK_COMPLAIN1( > >>> 139 "TEST FAILED: JVMTI_EVENT_CLASS_LOAD > >>> event received for\n" > >>> 140 "\t a primitive class/array of primitive > >>> types with the signature \"%s\"\n", > >>> 141 sig); > >>> > >>> thanks, > >>> > >>> Chris > >>> > >>> On 9/21/18 8:00 AM, JC Beyler wrote: > >>>> Hi all, > >>>> > >>>> Is anyone motivated on a Friday to review this ? :) > >>>> > >>>> It should be fairly straightforward :-) > >>>> > >>>> Thanks, > >>>> Jc > >>>> > >>>> On Tue, Sep 18, 2018 at 12:07 PM JC Beyler > >>>> > wrote: > >>>> > >>>> Hi all, > >>>> > >>>> Could I have a review for this webrev: > >>>> > >>>> Webrev: > >>>> > http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210689/webrev.00/> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > >>>> > >>>> Let me know what you think, > >>>> Jc > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Thanks, > >>>> Jc > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> Jc > >> > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > > > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Sat Sep 22 00:22:09 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 21 Sep 2018 17:22:09 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> Message-ID: LGTM. --alex On 09/21/2018 17:06, JC Beyler wrote: > Hi Alex, > > Good catch, it was not done on purpose but now fixed: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > Let me know if this works for you and thanks for the review, > Jc > > On Fri, Sep 21, 2018 at 3:44 PM Alex Menkov > wrote: > > Hi Jc, > > overall looks good (no changes in the logging) > except > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp > > : > -? ? if ((strcmp(name, expMeth) == 0) && > -? ? ? ? ? ? (strcmp(sig, expSig) == 0)) { > -? ? ? ? NSK_DISPLAY4("===== %s event received for the tested method:\n\ > -\tID=0x%p name=\"%s\" signature=\"%s\"\n", > +? ? if ((strcmp(name, expMeth) == 0) && (strcmp(sig, expSig) == 0)) { > +? ? ? ? NSK_DISPLAY4( > +? ? ? ? ? ? "%s event received for the tested method:\n" > +? ? ? ? ? ? "\tID=0x%p name=\"%s\" signature=\"%s\"\n", > > "===== " is dropped from the beginning of the line > I don't know if this is important. > > --alex > > > On 09/21/2018 14:29, JC Beyler wrote: > > Hi Chris, > > > > Done here: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.02/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > > > Anything else? and anybody else motivated to look? > > > > Thanks again! > > Jc > > > > On Fri, Sep 21, 2018 at 2:07 PM Chris Plummer > > > >> wrote: > > > >? ? ?Hi JC, > > > >? ? ?Overall looks good. Just a couple minor edits needed: > > > >? ? ?In nativemethbind003.cpp: > > > >? ? ? ?158???? NSK_DISPLAY1("Inside the registerNative()\nFinding > class > >? ? ?\"%s\" ...\n", CLASS_SIG); > > > >? ? ?This was two lines and you made it one with a \n in the middle of > >? ? ?the string. > > > >? ? ?In ap12t001.cpp: > > > >? ? ? ? 69???????? NSK_COMPLAIN2( > >? ? ? ? 70???????????? "Received unexpected number of ObjectFree > events: > >? ? ?%d\n" > >? ? ? ? 71???????????? "\texpected number: %d", > >? ? ? ? 72???????????? obj_free, EXP_OBJ_FREE); > > > >? ? ?There's no \n at the end of this output (and there never was). > >? ? ?Normally NSK_COMPLAIN is always used with a terminating \n. > > > >? ? ?thanks, > > > >? ? ?Chris > > > > > >? ? ?On 9/21/18 1:05 PM, JC Beyler wrote: > >>? ? ?Hi Chris, > >> > >>? ? ?Sounds good to me; here it is: > >>? ? ?Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ > > >>? ? ? > >>? ? ?Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > >> > >>? ? ?I admit I strived to stay consistent and always started a > new line > >>? ? ?for the multi-line argument even if the string was not too long; > >>? ? ?it's a question of style I believe but it felt more readable to > >>? ? ?me. I'll happily change whatever anyone prefers. > >> > >>? ? ?This has passed the vmTestbase tests I changed but due to the > >>? ? ?shared changes, I've launched a full vmTestbase testing now. > >> > >>? ? ?Let me know what you think, > >>? ? ?Jc > >> > >>? ? ?On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer > >>? ? ? > >> > wrote: > >> > >>? ? ? ? ?On 9/21/18 10:55 AM, JC Beyler wrote: > >>>? ? ? ? ?Hi Chris, > >>> > >>>? ? ? ? ?I hesitated to be honest and then thought that > debug_str was > >>>? ? ? ? ?better as you would clearly see that it is a multi-lilne > >>>? ? ? ? ?string and what parameters are what. But I'll take your > >>>? ? ? ? ?preference (it's relatively the same for me). Quick > question > >>>? ? ? ? ?though: > >>> > >>>? ? ? ? ?Do you have a preference between: > >>>? ? ? ? ? ? ? ? ? ? ? NSK_COMPLAIN6( > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "TEST FAILED: %s field \"%s\" has\n" > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "\tsignature: \"%s\"\n" > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "\tgeneric signature: \"%s\"\n\n" > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "\tExpected: \"%s\"\n" > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "\t\t\"%s\"\n\n", > >>>? ? ? ? ? ? ? ? ? ? ? ? ?(instance==0)?"instance":"static", > >>>? ? ? ? ? ? ? ? ? ? ? ? ? fld_sig[idx][0], > >>>? ? ? ? ? ? ? ? ? ? ? ? ? sign, (gen_sign==NULL)?"NULL":gen_sign, > >>>? ? ? ? ? ? ? ? ? ? ? ? ? fld_sig[idx][2], fld_sig[idx][3]); > >>>? ? ? ? ?or: > >>>? ? ? ? ? ? ? ? ? ? ? NSK_COMPLAIN6( > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "TEST FAILED: %s field \"%s\" > has\n\tsignature: \"%s\"\n" > >>>? ? ? ? ? ? ? ? ? ? ? ? ? "\tgeneric signature: > \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", > >>>? ? ? ? ? ? ? ? ? ? ? ? ?(instance==0)?"instance":"static", > >>>? ? ? ? ? ? ? ? ? ? ? ? ? fld_sig[idx][0], > >>>? ? ? ? ? ? ? ? ? ? ? ? ? sign, (gen_sign==NULL)?"NULL":gen_sign, > >>>? ? ? ? ? ? ? ? ? ? ? ? ? fld_sig[idx][2], fld_sig[idx][3]); > >>>? ? ? ? ?I think I like the first because you can clearly see > what we want to be printed out; but for code vertical > >>>? ? ? ? ?compression, the second is better. What do you think? > >>? ? ? ? ?I also prefer the first one. > >> > >>? ? ? ? ?thanks, > >> > >>? ? ? ? ?Chris > >>>? ? ? ? ?Thanks! > >>>? ? ? ? ?Jc > >>> > >>>? ? ? ? ?On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer > >>>? ? ? ? ? >> > >>>? ? ? ? ?wrote: > >>> > >>>? ? ? ? ? ? ?Hi JC, > >>> > >>>? ? ? ? ? ? ?I didn't realize you intended to move all the strings > >>>? ? ? ? ? ? ?into a "const char*" first. Seems unnecessary, and I > >>>? ? ? ? ? ? ?think not as easy to read: > >>> > >>>? ? ? ? ? ? ??138???????? const char* debug_str = > >>>? ? ? ? ? ? ??139???????????? "TEST FAILED: JVMTI_EVENT_CLASS_LOAD > >>>? ? ? ? ? ? ?event received for\n" > >>>? ? ? ? ? ? ??140???????????? "\t a primitive class/array of > primitive > >>>? ? ? ? ? ? ?types with the signature \"%s\"\n"; > >>>? ? ? ? ? ? ??141???????? NSK_COMPLAIN1(debug_str, sig); > >>> > >>>? ? ? ? ? ? ?vs > >>> > >>>? ? ? ? ? ? ??138???????? NSK_COMPLAIN1("TEST FAILED: > >>>? ? ? ? ? ? ?JVMTI_EVENT_CLASS_LOAD event received for\n" > >>>? ? ? ? ? ? ??139?????????????????????? "\t a primitive > class/array of > >>>? ? ? ? ? ? ?primitive types with the signature \"%s\"\n", > >>>? ? ? ? ? ? ??140?????????????????????? sig); > >>> > >>>? ? ? ? ? ? ?or > >>> > >>>? ? ? ? ? ? ??138???????? NSK_COMPLAIN1( > >>>? ? ? ? ? ? ??139???????????? "TEST FAILED: JVMTI_EVENT_CLASS_LOAD > >>>? ? ? ? ? ? ?event received for\n" > >>>? ? ? ? ? ? ?140 ??????????? "\t a primitive class/array of > primitive > >>>? ? ? ? ? ? ?types with the signature \"%s\"\n", > >>>? ? ? ? ? ? ?141 ??????????? sig); > >>> > >>>? ? ? ? ? ? ?thanks, > >>> > >>>? ? ? ? ? ? ?Chris > >>> > >>>? ? ? ? ? ? ?On 9/21/18 8:00 AM, JC Beyler wrote: > >>>>? ? ? ? ? ? ?Hi all, > >>>> > >>>>? ? ? ? ? ? ?Is anyone motivated on a Friday to review this ? :) > >>>> > >>>>? ? ? ? ? ? ?It should be fairly straightforward :-) > >>>> > >>>>? ? ? ? ? ? ?Thanks, > >>>>? ? ? ? ? ? ?Jc > >>>> > >>>>? ? ? ? ? ? ?On Tue, Sep 18, 2018 at 12:07 PM JC Beyler > >>>>? ? ? ? ? ? ? > >> wrote: > >>>> > >>>>? ? ? ? ? ? ? ? ?Hi all, > >>>> > >>>>? ? ? ? ? ? ? ? ?Could I have a review for this webrev: > >>>> > >>>>? ? ? ? ? ? ? ? ?Webrev: > >>>> http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ > > >>>> > ? > >>>>? ? ? ? ? ? ? ? ?Bug: > https://bugs.openjdk.java.net/browse/JDK-8210689 > >>>> > >>>>? ? ? ? ? ? ? ? ?Let me know what you think, > >>>>? ? ? ? ? ? ? ? ?Jc > >>>> > >>>> > >>>> > >>>>? ? ? ? ? ? ?-- > >>>> > >>>>? ? ? ? ? ? ?Thanks, > >>>>? ? ? ? ? ? ?Jc > >>> > >>> > >>> > >>> > >>>? ? ? ? ?-- > >>> > >>>? ? ? ? ?Thanks, > >>>? ? ? ? ?Jc > >> > >> > >> > >> > >>? ? ?-- > >> > >>? ? ?Thanks, > >>? ? ?Jc > > > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From gary.adams at oracle.com Sat Sep 22 10:45:42 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Sat, 22 Sep 2018 06:45:42 -0400 Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false Message-ID: This is a very old bug that started off as a closed test, but should have an open review before it finally gets pushed. Many other jdb bugs will be closed as duplicates as a result of this change. The problem shows up as a corrupted log when running the jdb tests. The tests send commands to a jdb process and parse the output to determine if the correct functions were performed. Sometimes the tests will timeout, sometimes the test will report the commands were not successful. When running jdb the output can come from several different threads. ??? - the command processing thread ??? - the event handler thread ??? - asynchronous command threads ??? - debuggee class (separate process) This fix works around an issue between the command thread and the event handler thread. In the TTY.executeCommand() method there is a large dispatch to commands that ends with the printing of a prompt for the user to enter another command. When commands {cont, next, step, stepi} are processed they resume the vm in the debuggee. This can cause the event handler to be woken up. Events typically display messages, such as "Breakpoint hit", "Step completed". They also set the current thread variable so a "current location" in the source can be identified. The event finishes by printing a prompt so the user will enter the next command. The corruption in the log shows up when the event handler starts running between the printing of the command and command issuing the prompt. It also shows up when a prompt is written in the middle of the event output. The proposed fix allows the {cont,next,step,stepi} commands to issue a simple prompt before performing the command that resumes the debuggee. It then skips the prompt that is issued at the end of the excuteCommand() dispatch. A variety of other fixes had been tried such as locks and output buffering, but all fell short. Many of the output routines are shared. Even the executeCommand() processing is called from the event handler thread to process monitor commands. ? Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.03/ This fix was tested with 1000 test runs on the slower debug builds where the problem was observed more often. Before the fix it was common to see 9/1000 failures on windows-x64 and solaris-sparc9 platforms. Here's a sample of a corrupted log. A prompt is displayed after an event header was displayed. As the next command is processed the rest of the event output shows up. ... Breakpoint hit: main[1] Sending command: locals reply[0]: "thread=main", nsk.jdb.locals.locals002.locals002a.allKindsOfLocals(), line=82 bci=62 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Sep 23 13:48:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 Sep 2018 09:48:38 -0400 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> Message-ID: <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> Hi Jc, Sorry for the delay on getting back to this but I'm travelling at the moment. This looks quite neat. Thanks also to Alex for all the suggestions. My only remaining concern is that static analysis tools may not like this because they may not be able to determine that we won't make subsequent JNI calls when an exception happens in the first. That's not a reason not to do this of course, just flagging that we may have to do something to deal with that problem. Thanks, David On 20/09/2018 11:56 AM, JC Beyler wrote: > Hi Alex, > > Done here, thanks for the review: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > Thanks again! > Jc > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > wrote: > > Hi Jc, > > Looks good to me. > A minor note: > - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid global > namespece pollution (ErrorHandler is too generic name). > > --alex > > On 09/19/2018 15:56, JC Beyler wrote: > > Hi Alex, > > > > I've updated the webrev to: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > That webrev has the code that is shown here in snippets. > > > > > > Thanks for the reviews, I've relatively followed your reviews > except for > > one detail due to me wanting to handle the NSK_JNI_VERIFY macros via > > this system as well later down the road. For an example: > > > > We currently have in the code: > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = NSK_CPP_STUB2(GetObjectClass, > > pEnv, mhToCall)) != NULL) ) > > > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor > (JDK-8210728) > > ?to: > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = pEnv->GetObjectClass(pEnv, > > mhToCall)) != NULL) ) > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it > becomes via > > this wrapping of JNIEnv: > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > > > > 3) Then, via removing the assignment, we'd arrive to a: > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > if (!mhClass) > > > > Without any loss of checking for failures, etc. > > > > So that is my motivation for most of this work with a concrete > example > > (hopefully it helps drive this conversation). > > > > I inlined my answers here, let me know?what you think. > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?Updated tests looks good. > >? ? ?Some notes about implementation. > > > >? ? ?- FatalOnException implements both verification and error > handling > >? ? ?It would be better to separate them (and this makes easy to > implement > >? ? ?error handling different from JNIEnv::FatalError). > >? ? ?The simplest way is to define error handler as > >? ? ?class SafeJNIEnv { > >? ? ?public: > >? ? ? ? ? ?typedef void (*ErrorHandler)(JNIEnv *env, const char* > errorMsg); > >? ? ? ? ? ?// error handler which terminates jvm by using FatalError() > >? ? ? ? ? ?static void FatalError(JNIEnv *env, const char *errrorMsg); > > > >? ? ? ? ? ?SafeJNIEnv(JNIEnv* jni_env, ErrorHandler errorHandler = > >? ? ?FatalError); > >? ? ?(SafeJNIEnv methods should create FatalOnException objects > passing > >? ? ?errorHandler) > > > > > > > > Agreed, I tried to keep the code simple. The concepts you talk about > > here are generally what I reserve for when I need it (ie > extensions and > > handling new cases). But a lot are going to be needed soon so I > think it > > is a good time to iron the code out now on this "simple" webrev. > > > > So done for this. > > > > > > > >? ? ?- FatalOnException is used in SafeJNIEnv methods as > >? ? ? ? ?FatalOnException marker(this, "msg"); > >? ? ? ? ?ret = > >? ? ? ? ?(optional)marker.check_for_null(ret); > >? ? ? ? ?return ret; > >? ? ?But actually I'd call it something like JNICallResultVerifier and > >? ? ?create > >? ? ?the object after JNI call. like > >? ? ? ? ?ret = > >? ? ? ? ?JNICallResultVerifier(this, "msg") > >? ? ? ? ? ?(optional).notNull(ret); > >? ? ? ? ?return ret; > >? ? ?or even (if you like such syntax sugar) you can define > >? ? ? ? ?template > >? ? ? ? ?T resultNotNull(T result) { > >? ? ? ? ? ? ?notNull(result); > >? ? ? ? ? ? ?return result; > >? ? ? ? ?} > >? ? ?and do > >? ? ? ? ?ret = > >? ? ? ? ?return JNICallResultVerifier(this, "msg").resultNotNull(ret); > > > > > > So I renamed FatalOnException to now being JNIVerifier. > > > > Though I like it, I don't think we can do it, except if we do it > > slightly differently: > > I'm trying to solve two problems with one stone: > >? ? ?- How to check for returns of JNI calls in the way that is > done here > >? ? ?- How to remove NSK_JNI_VERIFY* (from nsk/share/jni/jni_tools) > > > > However, the NSK_JNI_VERIFY need to start a tracing system before > the > > call to JNI, so it won't work this way. (Side question would be > do we > > still care about the tracing in NSK_JNI_VERIFY, if we don't then > your > > solution works well in most situations). > > > > My vision or intuition is that we would throw a template at some > point > > on SafeJNIEnv to handle both cases and have JNIVerifier become a > > specialization in certain cases and something different for the > > NSK_JNI_VERIFY case (or have a different constructor to enable > tracing). > > But for now, I offer the implementation that does: > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > >? ? JNIVerifier marker(this, "GetObjectClass"); > >? ? return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > } > > > > and: > > > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID field, jobject > > value) { > >? ? JNIVerifier<> marker(this, "SetObjectField"); > >? ? _jni_env->SetObjectField(obj, field, value); > > } > > > > > > > > > >? ? ?- you added #include in the test (and you have to > add it to > >? ? ?every test). > >? ? ?It would be simpler to add the include to SafeJNIEnv.hpp and > define > >? ? ?typedef std::unique_ptr SafeJNIEnvPtr; > >? ? ?Then each in the test methods: > >? ? ? ? ?SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > >? ? ?or you can add > >? ? ?static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, > ErrorHandler > >? ? ?errorHandler = fatalError) > >? ? ?and get > >? ? ? ? ?SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > > > > > > Done, I like that, even less code change to tests then. > > > > > > > >? ? ?- it would be better to wrap internal classes > (FatalOnException) into > >? ? ?unnamed namespace - this helps to avoid conflicts with other > classes) > > > >? ? ?- FatalOnException::check_for_null(void* ptr) > >? ? ?should be > >? ? ?FatalOnException::check_for_null(const void* ptr) > >? ? ?And calling the method you don't need reinterpret_cast > > > > > > Also done, it got renamed to ResultNotNull, is using a template > now, but > > agreed, that worked. > > Thanks again for the review, > > Jc > > > > > >? ? ?--alex > > > > > >? ? ?On 09/18/2018 11:07, JC Beyler wrote: > >? ? ? > Hi David, > >? ? ? > > >? ? ? > Thanks for the quick review and thoughts. I have now a new > >? ? ?version here > >? ? ? > that addresses your comments: > >? ? ? > > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > >? ? ? > >? ? ? > > >? ? ? > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? > > >? ? ? > I've also inlined my answers/comments. > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? >? ? ? > I've slowly started working on JDK-8191519 > >? ? ? >? ? ? > . > >? ? ?However before > >? ? ? >? ? ? > starting to really refactor all the tests, I > thought I'd > >? ? ?get a few > >? ? ? >? ? ? > opinions.?I am working on internalizing the error > handling > >? ? ?of JNI > >? ? ? >? ? ?calls > >? ? ? >? ? ? > via a SafeJNIEnv class that redefines all the JNI > calls to > >? ? ?add an > >? ? ? >? ? ?error > >? ? ? >? ? ? > checker. > >? ? ? >? ? ? > > >? ? ? >? ? ? > The advantage is that the test code will look and > feel like > >? ? ? >? ? ?normal JNI > >? ? ? >? ? ? > code and calls but will have the checks we want to have > >? ? ?for our > >? ? ? >? ? ?tests. > >? ? ? > > >? ? ? >? ? ?Not sure I get that. Normal JNI code has to check for > >? ? ?errors/exceptions > >? ? ? >? ? ?after every call. The tests need those checks too. > Today they are > >? ? ? >? ? ?explicit, with this change they become implicit. Not sure > >? ? ?what we are > >? ? ? >? ? ?gaining here ?? > >? ? ? > > >? ? ? > > >? ? ? > In my humble opinion, having the error checking out of the way > >? ? ?allows > >? ? ? > the code reader to concentrate on the JNI code while > maintaining > >? ? ?error > >? ? ? > checking. We use something similar internally, so perhaps I'm > >? ? ?biased to > >? ? ? > it :-). > >? ? ? > If this is not a desired/helpful "feature" to simplify > tests in > >? ? ?general, > >? ? ? > I will backtrack it and just add the explicit tests to the > native > >? ? ?code > >? ? ? > of the locks for the fix > >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8191519?instead. > >? ? ? > > >? ? ? > Let me however try to make my case and let me know what > you all > >? ? ?think! > >? ? ? > > >? ? ? > > >? ? ? >? ? ? > If agreed with this, we can augment the SafeJNIEnv > class > >? ? ?as needed. > >? ? ? >? ? ? > Also, if the tests require something else than fatal > >? ? ?errors, we > >? ? ? >? ? ?can add > >? ? ? >? ? ? > a different marker and make it a parameter to the > base class. > >? ? ? >? ? ? > > >? ? ? >? ? ? > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > > >? ? ? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? >? ? ? > > >? ? ? >? ? ? > Let me know what you think, > >? ? ? > > >? ? ? >? ? ?Two initial suggestions: > >? ? ? > > >? ? ? >? ? ?1. FatalOnException should be constructed with a > description > >? ? ?string so > >? ? ? >? ? ?that it can report the failing operation when calling > >? ? ?FatalError rather > >? ? ? >? ? ?than the general "Problem with a JNI call". > >? ? ? > > >? ? ? > > >? ? ? > Agreed with you, the new webrev produces: > >? ? ? > > >? ? ? > FATAL ERROR in native method: GetObjectClass > >? ? ? >? ? ? ? ? at > > > ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > >? ? ? >? ? ? ? ? at > >? ? ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ?Method) > >? ? ? >? ? ? ? ? at > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? >? ? ? ? ? at > > > ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > >? ? ? >? ? ? ? ? at > >? ? ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > >? ? ? > > >? ? ? > > >? ? ? > and for a return NULL in NewGlobalRef, we would get > automatically: > >? ? ? > > >? ? ? > FATAL ERROR in native method: NewGlobalRef:Return is NULL > >? ? ? >? ? ? ? ? at > >? ? ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ?Method) > >? ? ? > > >? ? ? >? ? ? ? ? at > >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > Again as we port and simplify more tests (I'll only do the > locks > >? ? ?for now > >? ? ? > and we can figure out the next steps as start working on > moving > >? ? ?tests > >? ? ? > out of vmTestbase), > >? ? ? > we can add, if needed, other exception handlers that don't > throw > >? ? ?or do > >? ? ? > other things depending on the JNI method outputs. > >? ? ? > > >? ? ? > > >? ? ? >? ? ?2. Make the local SafeJNIEnv a pointer called env so > that the > >? ? ?change is > >? ? ? >? ? ?less disruptive. All the env->op() calls will remain > and only > >? ? ?the local > >? ? ? >? ? ?error checking will be removed. > >? ? ? > > >? ? ? > > >? ? ? > Done, I used a unique_ptr to make the object > >? ? ?created/destroyed/available > >? ? ? > as a pointer do-able in one line: > >? ? ? > std::unique_ptr env(new SafeJNIEnv(jni_env)); > >? ? ? > > >? ? ? > and then you can see that, as you mentioned, the disruption to > >? ? ?the code > >? ? ? > is much less: > >? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > ? > > > >? ? ? > > > > ? > >? ? ? > > >? ? ? > Basically the tests now become internal to the SafeJNIEnv > and the > >? ? ?code > >? ? ? > now only contains the JNI calls happening but we are protected > >? ? ?and will > >? ? ? > fail any test that has an exception or a NULL return for the > >? ? ?call. Of > >? ? ? > course, this is not 100% proof in terms of not having any > error > >? ? ?handling > >? ? ? > in the test but in some cases like this, the new code seems to > >? ? ?just work > >? ? ? > better: > >? ? ? > > >? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > ? > > > >? ? ? > > > > ? > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? >? ? ?The switch from, e.g., checking NULL returns to > checking for > >? ? ?pending > >? ? ? >? ? ?exceptions, need to be sure that the JNI operations > clearly > >? ? ?specify > >? ? ? >? ? ?that > >? ? ? >? ? ?NULL implies there will be an exception pending. This > change > >? ? ?may be an > >? ? ? >? ? ?issue for static code analysis if not smart enough to > >? ? ?understand the > >? ? ? >? ? ?RAII wrappers. > >? ? ? > > >? ? ? > > >? ? ? > Agreed, I fixed it to be more strict and say: in normal test > >? ? ?handling, > >? ? ? > the JNI calls should never return NULL or throw an > exception. This > >? ? ? > should hold for tests I imagine but if not we can add a > different > >? ? ?call > >? ? ? > verifier as we go. > >? ? ? > > >? ? ? > > >? ? ? >? ? ?Thanks, > >? ? ? >? ? ?David > >? ? ? > > >? ? ? >? ? ? > Jc > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > Let me know what you all think. When talking about it a > bit, I had > >? ? ? > gotten some interest to see what it would look like. Here > it is > >? ? ?:-). Now > >? ? ? > if it is not wanted like I said, I can backtrack and just > put the > >? ? ?error > >? ? ? > checks after each JNI call for all the tests as we are > porting them. > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From jcbeyler at google.com Sun Sep 23 16:17:04 2018 From: jcbeyler at google.com (JC Beyler) Date: Sun, 23 Sep 2018 09:17:04 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> Message-ID: Hi David, No worries with the time to answer; I appreciate the review! That's a fair point. Is it possible to "describe" to the static analysis tool to "trust" calls made in the SafeJNIEnv class? Otherwise, do you have any idea on how to go forward? For what it's worth, this current webrev does not try to replace exception checking with the SafeJNIEnv (it actually adds it), so for now the question/solution could be delayed. I could continue working on this in the scope of both the nsk/gc/lock/jniref code base and the NSK_VERIFIER macro removal and we can look at how to tackle the cases where the tests are actually calling exception checking (I know my heapmonitor does for example). Let me know what you think and thanks for the review, Jc On Sun, Sep 23, 2018 at 6:48 AM David Holmes wrote: > Hi Jc, > > Sorry for the delay on getting back to this but I'm travelling at the > moment. > > This looks quite neat. Thanks also to Alex for all the suggestions. > > My only remaining concern is that static analysis tools may not like > this because they may not be able to determine that we won't make > subsequent JNI calls when an exception happens in the first. That's not > a reason not to do this of course, just flagging that we may have to do > something to deal with that problem. > > Thanks, > David > > On 20/09/2018 11:56 AM, JC Beyler wrote: > > Hi Alex, > > > > Done here, thanks for the review: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > Thanks again! > > Jc > > > > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > Looks good to me. > > A minor note: > > - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid global > > namespece pollution (ErrorHandler is too generic name). > > > > --alex > > > > On 09/19/2018 15:56, JC Beyler wrote: > > > Hi Alex, > > > > > > I've updated the webrev to: > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > That webrev has the code that is shown here in snippets. > > > > > > > > > Thanks for the reviews, I've relatively followed your reviews > > except for > > > one detail due to me wanting to handle the NSK_JNI_VERIFY macros > via > > > this system as well later down the road. For an example: > > > > > > We currently have in the code: > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > NSK_CPP_STUB2(GetObjectClass, > > > pEnv, mhToCall)) != NULL) ) > > > > > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor > > (JDK-8210728) > > > to: > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = pEnv->GetObjectClass(pEnv, > > > mhToCall)) != NULL) ) > > > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it > > becomes via > > > this wrapping of JNIEnv: > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > > > > > > 3) Then, via removing the assignment, we'd arrive to a: > > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > > if (!mhClass) > > > > > > Without any loss of checking for failures, etc. > > > > > > So that is my motivation for most of this work with a concrete > > example > > > (hopefully it helps drive this conversation). > > > > > > I inlined my answers here, let me know what you think. > > > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > > > > > >> wrote: > > > > > > Hi Jc, > > > > > > Updated tests looks good. > > > Some notes about implementation. > > > > > > - FatalOnException implements both verification and error > > handling > > > It would be better to separate them (and this makes easy to > > implement > > > error handling different from JNIEnv::FatalError). > > > The simplest way is to define error handler as > > > class SafeJNIEnv { > > > public: > > > typedef void (*ErrorHandler)(JNIEnv *env, const char* > > errorMsg); > > > // error handler which terminates jvm by using > FatalError() > > > static void FatalError(JNIEnv *env, const char > *errrorMsg); > > > > > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler errorHandler = > > > FatalError); > > > (SafeJNIEnv methods should create FatalOnException objects > > passing > > > errorHandler) > > > > > > > > > > > > Agreed, I tried to keep the code simple. The concepts you talk > about > > > here are generally what I reserve for when I need it (ie > > extensions and > > > handling new cases). But a lot are going to be needed soon so I > > think it > > > is a good time to iron the code out now on this "simple" webrev. > > > > > > So done for this. > > > > > > > > > > > > - FatalOnException is used in SafeJNIEnv methods as > > > FatalOnException marker(this, "msg"); > > > ret = > > > (optional)marker.check_for_null(ret); > > > return ret; > > > But actually I'd call it something like JNICallResultVerifier > and > > > create > > > the object after JNI call. like > > > ret = > > > JNICallResultVerifier(this, "msg") > > > (optional).notNull(ret); > > > return ret; > > > or even (if you like such syntax sugar) you can define > > > template > > > T resultNotNull(T result) { > > > notNull(result); > > > return result; > > > } > > > and do > > > ret = > > > return JNICallResultVerifier(this, > "msg").resultNotNull(ret); > > > > > > > > > So I renamed FatalOnException to now being JNIVerifier. > > > > > > Though I like it, I don't think we can do it, except if we do it > > > slightly differently: > > > I'm trying to solve two problems with one stone: > > > - How to check for returns of JNI calls in the way that is > > done here > > > - How to remove NSK_JNI_VERIFY* (from nsk/share/jni/jni_tools) > > > > > > However, the NSK_JNI_VERIFY need to start a tracing system before > > the > > > call to JNI, so it won't work this way. (Side question would be > > do we > > > still care about the tracing in NSK_JNI_VERIFY, if we don't then > > your > > > solution works well in most situations). > > > > > > My vision or intuition is that we would throw a template at some > > point > > > on SafeJNIEnv to handle both cases and have JNIVerifier become a > > > specialization in certain cases and something different for the > > > NSK_JNI_VERIFY case (or have a different constructor to enable > > tracing). > > > But for now, I offer the implementation that does: > > > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > > > JNIVerifier marker(this, "GetObjectClass"); > > > return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > > } > > > > > > and: > > > > > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID field, > jobject > > > value) { > > > JNIVerifier<> marker(this, "SetObjectField"); > > > _jni_env->SetObjectField(obj, field, value); > > > } > > > > > > > > > > > > > > > - you added #include in the test (and you have to > > add it to > > > every test). > > > It would be simpler to add the include to SafeJNIEnv.hpp and > > define > > > typedef std::unique_ptr SafeJNIEnvPtr; > > > Then each in the test methods: > > > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > > > or you can add > > > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, > > ErrorHandler > > > errorHandler = fatalError) > > > and get > > > SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > > > > > > > > > Done, I like that, even less code change to tests then. > > > > > > > > > > > > - it would be better to wrap internal classes > > (FatalOnException) into > > > unnamed namespace - this helps to avoid conflicts with other > > classes) > > > > > > - FatalOnException::check_for_null(void* ptr) > > > should be > > > FatalOnException::check_for_null(const void* ptr) > > > And calling the method you don't need reinterpret_cast > > > > > > > > > Also done, it got renamed to ResultNotNull, is using a template > > now, but > > > agreed, that worked. > > > Thanks again for the review, > > > Jc > > > > > > > > > --alex > > > > > > > > > On 09/18/2018 11:07, JC Beyler wrote: > > > > Hi David, > > > > > > > > Thanks for the quick review and thoughts. I have now a new > > > version here > > > > that addresses your comments: > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > > > > > > > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > I've also inlined my answers/comments. > > > > > > > > > > > > > > > > > I've slowly started working on JDK-8191519 > > > > > . > > > However before > > > > > starting to really refactor all the tests, I > > thought I'd > > > get a few > > > > > opinions. I am working on internalizing the error > > handling > > > of JNI > > > > calls > > > > > via a SafeJNIEnv class that redefines all the JNI > > calls to > > > add an > > > > error > > > > > checker. > > > > > > > > > > The advantage is that the test code will look and > > feel like > > > > normal JNI > > > > > code and calls but will have the checks we want to > have > > > for our > > > > tests. > > > > > > > > Not sure I get that. Normal JNI code has to check for > > > errors/exceptions > > > > after every call. The tests need those checks too. > > Today they are > > > > explicit, with this change they become implicit. Not > sure > > > what we are > > > > gaining here ?? > > > > > > > > > > > > In my humble opinion, having the error checking out of the > way > > > allows > > > > the code reader to concentrate on the JNI code while > > maintaining > > > error > > > > checking. We use something similar internally, so perhaps > I'm > > > biased to > > > > it :-). > > > > If this is not a desired/helpful "feature" to simplify > > tests in > > > general, > > > > I will backtrack it and just add the explicit tests to the > > native > > > code > > > > of the locks for the fix > > > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > > > > > Let me however try to make my case and let me know what > > you all > > > think! > > > > > > > > > > > > > If agreed with this, we can augment the SafeJNIEnv > > class > > > as needed. > > > > > Also, if the tests require something else than fatal > > > errors, we > > > > can add > > > > > a different marker and make it a parameter to the > > base class. > > > > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > > > > > > > > > > > > > > > > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > Let me know what you think, > > > > > > > > Two initial suggestions: > > > > > > > > 1. FatalOnException should be constructed with a > > description > > > string so > > > > that it can report the failing operation when calling > > > FatalError rather > > > > than the general "Problem with a JNI call". > > > > > > > > > > > > Agreed with you, the new webrev produces: > > > > > > > > FATAL ERROR in native method: GetObjectClass > > > > at > > > > > > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > > > at > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > Method) > > > > at > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > at > > > > > > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > > > at > > > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > > > > > > > and for a return NULL in NewGlobalRef, we would get > > automatically: > > > > > > > > FATAL ERROR in native method: NewGlobalRef:Return is NULL > > > > at > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > Method) > > > > > > > > at > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > > > > > > > > > > > Again as we port and simplify more tests (I'll only do the > > locks > > > for now > > > > and we can figure out the next steps as start working on > > moving > > > tests > > > > out of vmTestbase), > > > > we can add, if needed, other exception handlers that don't > > throw > > > or do > > > > other things depending on the JNI method outputs. > > > > > > > > > > > > 2. Make the local SafeJNIEnv a pointer called env so > > that the > > > change is > > > > less disruptive. All the env->op() calls will remain > > and only > > > the local > > > > error checking will be removed. > > > > > > > > > > > > Done, I used a unique_ptr to make the object > > > created/destroyed/available > > > > as a pointer do-able in one line: > > > > std::unique_ptr env(new SafeJNIEnv(jni_env)); > > > > > > > > and then you can see that, as you mentioned, the > disruption to > > > the code > > > > is much less: > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > Basically the tests now become internal to the SafeJNIEnv > > and the > > > code > > > > now only contains the JNI calls happening but we are > protected > > > and will > > > > fail any test that has an exception or a NULL return for > the > > > call. Of > > > > course, this is not 100% proof in terms of not having any > > error > > > handling > > > > in the test but in some cases like this, the new code > seems to > > > just work > > > > better: > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > The switch from, e.g., checking NULL returns to > > checking for > > > pending > > > > exceptions, need to be sure that the JNI operations > > clearly > > > specify > > > > that > > > > NULL implies there will be an exception pending. This > > change > > > may be an > > > > issue for static code analysis if not smart enough to > > > understand the > > > > RAII wrappers. > > > > > > > > > > > > Agreed, I fixed it to be more strict and say: in normal > test > > > handling, > > > > the JNI calls should never return NULL or throw an > > exception. This > > > > should hold for tests I imagine but if not we can add a > > different > > > call > > > > verifier as we go. > > > > > > > > > > > > Thanks, > > > > David > > > > > > > > > Jc > > > > > > > > > > > > > > > > Let me know what you all think. When talking about it a > > bit, I had > > > > gotten some interest to see what it would look like. Here > > it is > > > :-). Now > > > > if it is not wanted like I said, I can backtrack and just > > put the > > > error > > > > checks after each JNI call for all the tests as we are > > porting them. > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Sep 23 16:22:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 Sep 2018 12:22:40 -0400 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> Message-ID: <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> Hi Jc, I don't think it is an issue for this to go ahead. If the static analysis tool has an issue then we can either find out how to teach it about this code structure, or else flag the issues as false positives. I'd be relying on one of the serviceability team here to handle that if the problem arises. Thanks, David On 23/09/2018 12:17 PM, JC Beyler wrote: > Hi David, > > No worries with the time to answer; I appreciate the review! > > That's a fair point. Is it possible to "describe" to the static analysis > tool to "trust" calls made in the SafeJNIEnv class? > > Otherwise, do you have any idea on how to go forward? For what it's > worth, this current webrev does not try to replace exception checking > with the SafeJNIEnv (it actually adds it), so for now the > question/solution could be delayed. I could continue working on this in > the scope of both the nsk/gc/lock/jniref code base and the NSK_VERIFIER > macro removal and we can look at how to tackle the cases where the tests > are actually calling exception checking (I know my heapmonitor does for > example). > > Let me know what you think and thanks for the review, > Jc > > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > wrote: > > Hi Jc, > > Sorry for the delay on getting back to this but I'm travelling at the > moment. > > This looks quite neat. Thanks also to Alex for all the suggestions. > > My only remaining concern is that static analysis tools may not like > this because they may not be able to determine that we won't make > subsequent JNI calls when an exception happens in the first. That's not > a reason not to do this of course, just flagging that we may have to do > something to deal with that problem. > > Thanks, > David > > On 20/09/2018 11:56 AM, JC Beyler wrote: > > Hi Alex, > > > > Done here, thanks for the review: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > Thanks again! > > Jc > > > > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?Looks good to me. > >? ? ?A minor note: > >? ? ?- I'd move ErrorHandler typedef to SafeJNIEnv class to avoid > global > >? ? ?namespece pollution (ErrorHandler is too generic name). > > > >? ? ?--alex > > > >? ? ?On 09/19/2018 15:56, JC Beyler wrote: > >? ? ? > Hi Alex, > >? ? ? > > >? ? ? > I've updated the webrev to: > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > >? ? ? > >? ? ? > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? > > >? ? ? > That webrev has the code that is shown here in snippets. > >? ? ? > > >? ? ? > > >? ? ? > Thanks for the reviews, I've relatively followed your reviews > >? ? ?except for > >? ? ? > one detail due to me wanting to handle the NSK_JNI_VERIFY > macros via > >? ? ? > this system as well later down the road. For an example: > >? ? ? > > >? ? ? > We currently have in the code: > >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > NSK_CPP_STUB2(GetObjectClass, > >? ? ? > pEnv, mhToCall)) != NULL) ) > >? ? ? > > >? ? ? > 1) The NSK_CPP_STUB2 is trivially removed with a refactor > >? ? ?(JDK-8210728) > >? ? ? > ?to: > >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > pEnv->GetObjectClass(pEnv, > >? ? ? > mhToCall)) != NULL) ) > >? ? ? > > >? ? ? > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it > >? ? ?becomes via > >? ? ? > this wrapping of JNIEnv: > >? ? ? > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > >? ? ? > > >? ? ? > 3) Then, via removing the assignment, we'd arrive to a: > >? ? ? > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > >? ? ? > if (!mhClass) > >? ? ? > > >? ? ? > Without any loss of checking for failures, etc. > >? ? ? > > >? ? ? > So that is my motivation for most of this work with a concrete > >? ? ?example > >? ? ? > (hopefully it helps drive this conversation). > >? ? ? > > >? ? ? > I inlined my answers here, let me know?what you think. > >? ? ? > > >? ? ? > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > >? ? ? > > > >? ? ? > > >? ? ? >>> wrote: > >? ? ? > > >? ? ? >? ? ?Hi Jc, > >? ? ? > > >? ? ? >? ? ?Updated tests looks good. > >? ? ? >? ? ?Some notes about implementation. > >? ? ? > > >? ? ? >? ? ?- FatalOnException implements both verification and error > >? ? ?handling > >? ? ? >? ? ?It would be better to separate them (and this makes > easy to > >? ? ?implement > >? ? ? >? ? ?error handling different from JNIEnv::FatalError). > >? ? ? >? ? ?The simplest way is to define error handler as > >? ? ? >? ? ?class SafeJNIEnv { > >? ? ? >? ? ?public: > >? ? ? >? ? ? ? ? ?typedef void (*ErrorHandler)(JNIEnv *env, const > char* > >? ? ?errorMsg); > >? ? ? >? ? ? ? ? ?// error handler which terminates jvm by using > FatalError() > >? ? ? >? ? ? ? ? ?static void FatalError(JNIEnv *env, const char > *errrorMsg); > >? ? ? > > >? ? ? >? ? ? ? ? ?SafeJNIEnv(JNIEnv* jni_env, ErrorHandler > errorHandler = > >? ? ? >? ? ?FatalError); > >? ? ? >? ? ?(SafeJNIEnv methods should create FatalOnException objects > >? ? ?passing > >? ? ? >? ? ?errorHandler) > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > Agreed, I tried to keep the code simple. The concepts you > talk about > >? ? ? > here are generally what I reserve for when I need it (ie > >? ? ?extensions and > >? ? ? > handling new cases). But a lot are going to be needed soon > so I > >? ? ?think it > >? ? ? > is a good time to iron the code out now on this "simple" > webrev. > >? ? ? > > >? ? ? > So done for this. > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? >? ? ?- FatalOnException is used in SafeJNIEnv methods as > >? ? ? >? ? ? ? ?FatalOnException marker(this, "msg"); > >? ? ? >? ? ? ? ?ret = > >? ? ? >? ? ? ? ?(optional)marker.check_for_null(ret); > >? ? ? >? ? ? ? ?return ret; > >? ? ? >? ? ?But actually I'd call it something like > JNICallResultVerifier and > >? ? ? >? ? ?create > >? ? ? >? ? ?the object after JNI call. like > >? ? ? >? ? ? ? ?ret = > >? ? ? >? ? ? ? ?JNICallResultVerifier(this, "msg") > >? ? ? >? ? ? ? ? ?(optional).notNull(ret); > >? ? ? >? ? ? ? ?return ret; > >? ? ? >? ? ?or even (if you like such syntax sugar) you can define > >? ? ? >? ? ? ? ?template > >? ? ? >? ? ? ? ?T resultNotNull(T result) { > >? ? ? >? ? ? ? ? ? ?notNull(result); > >? ? ? >? ? ? ? ? ? ?return result; > >? ? ? >? ? ? ? ?} > >? ? ? >? ? ?and do > >? ? ? >? ? ? ? ?ret = > >? ? ? >? ? ? ? ?return JNICallResultVerifier(this, > "msg").resultNotNull(ret); > >? ? ? > > >? ? ? > > >? ? ? > So I renamed FatalOnException to now being JNIVerifier. > >? ? ? > > >? ? ? > Though I like it, I don't think we can do it, except if we > do it > >? ? ? > slightly differently: > >? ? ? > I'm trying to solve two problems with one stone: > >? ? ? >? ? ?- How to check for returns of JNI calls in the way that is > >? ? ?done here > >? ? ? >? ? ?- How to remove NSK_JNI_VERIFY* (from > nsk/share/jni/jni_tools) > >? ? ? > > >? ? ? > However, the NSK_JNI_VERIFY need to start a tracing system > before > >? ? ?the > >? ? ? > call to JNI, so it won't work this way. (Side question > would be > >? ? ?do we > >? ? ? > still care about the tracing in NSK_JNI_VERIFY, if we > don't then > >? ? ?your > >? ? ? > solution works well in most situations). > >? ? ? > > >? ? ? > My vision or intuition is that we would throw a template > at some > >? ? ?point > >? ? ? > on SafeJNIEnv to handle both cases and have JNIVerifier > become a > >? ? ? > specialization in certain cases and something different > for the > >? ? ? > NSK_JNI_VERIFY case (or have a different constructor to enable > >? ? ?tracing). > >? ? ? > But for now, I offer the implementation that does: > >? ? ? > > >? ? ? > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > >? ? ? >? ? JNIVerifier marker(this, "GetObjectClass"); > >? ? ? >? ? return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > >? ? ? > } > >? ? ? > > >? ? ? > and: > >? ? ? > > >? ? ? > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID > field, jobject > >? ? ? > value) { > >? ? ? >? ? JNIVerifier<> marker(this, "SetObjectField"); > >? ? ? >? ? _jni_env->SetObjectField(obj, field, value); > >? ? ? > } > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? >? ? ?- you added #include in the test (and you have to > >? ? ?add it to > >? ? ? >? ? ?every test). > >? ? ? >? ? ?It would be simpler to add the include to > SafeJNIEnv.hpp and > >? ? ?define > >? ? ? >? ? ?typedef std::unique_ptr SafeJNIEnvPtr; > >? ? ? >? ? ?Then each in the test methods: > >? ? ? >? ? ? ? ?SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > >? ? ? >? ? ?or you can add > >? ? ? >? ? ?static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, > >? ? ?ErrorHandler > >? ? ? >? ? ?errorHandler = fatalError) > >? ? ? >? ? ?and get > >? ? ? >? ? ? ? ?SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > >? ? ? > > >? ? ? > > >? ? ? > Done, I like that, even less code change to tests then. > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? >? ? ?- it would be better to wrap internal classes > >? ? ?(FatalOnException) into > >? ? ? >? ? ?unnamed namespace - this helps to avoid conflicts with > other > >? ? ?classes) > >? ? ? > > >? ? ? >? ? ?- FatalOnException::check_for_null(void* ptr) > >? ? ? >? ? ?should be > >? ? ? >? ? ?FatalOnException::check_for_null(const void* ptr) > >? ? ? >? ? ?And calling the method you don't need reinterpret_cast > >? ? ? > > >? ? ? > > >? ? ? > Also done, it got renamed to ResultNotNull, is using a > template > >? ? ?now, but > >? ? ? > agreed, that worked. > >? ? ? > Thanks again for the review, > >? ? ? > Jc > >? ? ? > > >? ? ? > > >? ? ? >? ? ?--alex > >? ? ? > > >? ? ? > > >? ? ? >? ? ?On 09/18/2018 11:07, JC Beyler wrote: > >? ? ? >? ? ? > Hi David, > >? ? ? >? ? ? > > >? ? ? >? ? ? > Thanks for the quick review and thoughts. I have > now a new > >? ? ? >? ? ?version here > >? ? ? >? ? ? > that addresses your comments: > >? ? ? >? ? ? > > >? ? ? >? ? ? > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > > >? ? ? >? ? ? > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? >? ? ? > > >? ? ? >? ? ? > I've also inlined my answers/comments. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > I've slowly started working on JDK-8191519 > >? ? ? >? ? ? >? ? ? > > . > >? ? ? >? ? ?However before > >? ? ? >? ? ? >? ? ? > starting to really refactor all the tests, I > >? ? ?thought I'd > >? ? ? >? ? ?get a few > >? ? ? >? ? ? >? ? ? > opinions.?I am working on internalizing the > error > >? ? ?handling > >? ? ? >? ? ?of JNI > >? ? ? >? ? ? >? ? ?calls > >? ? ? >? ? ? >? ? ? > via a SafeJNIEnv class that redefines all > the JNI > >? ? ?calls to > >? ? ? >? ? ?add an > >? ? ? >? ? ? >? ? ?error > >? ? ? >? ? ? >? ? ? > checker. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > The advantage is that the test code will > look and > >? ? ?feel like > >? ? ? >? ? ? >? ? ?normal JNI > >? ? ? >? ? ? >? ? ? > code and calls but will have the checks we > want to have > >? ? ? >? ? ?for our > >? ? ? >? ? ? >? ? ?tests. > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?Not sure I get that. Normal JNI code has to > check for > >? ? ? >? ? ?errors/exceptions > >? ? ? >? ? ? >? ? ?after every call. The tests need those checks too. > >? ? ?Today they are > >? ? ? >? ? ? >? ? ?explicit, with this change they become > implicit. Not sure > >? ? ? >? ? ?what we are > >? ? ? >? ? ? >? ? ?gaining here ?? > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > In my humble opinion, having the error checking out > of the way > >? ? ? >? ? ?allows > >? ? ? >? ? ? > the code reader to concentrate on the JNI code while > >? ? ?maintaining > >? ? ? >? ? ?error > >? ? ? >? ? ? > checking. We use something similar internally, so > perhaps I'm > >? ? ? >? ? ?biased to > >? ? ? >? ? ? > it :-). > >? ? ? >? ? ? > If this is not a desired/helpful "feature" to simplify > >? ? ?tests in > >? ? ? >? ? ?general, > >? ? ? >? ? ? > I will backtrack it and just add the explicit tests > to the > >? ? ?native > >? ? ? >? ? ?code > >? ? ? >? ? ? > of the locks for the fix > >? ? ? >? ? ? > > https://bugs.openjdk.java.net/browse/JDK-8191519?instead. > >? ? ? >? ? ? > > >? ? ? >? ? ? > Let me however try to make my case and let me know what > >? ? ?you all > >? ? ? >? ? ?think! > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > If agreed with this, we can augment the > SafeJNIEnv > >? ? ?class > >? ? ? >? ? ?as needed. > >? ? ? >? ? ? >? ? ? > Also, if the tests require something else > than fatal > >? ? ? >? ? ?errors, we > >? ? ? >? ? ? >? ? ?can add > >? ? ? >? ? ? >? ? ? > a different marker and make it a parameter > to the > >? ? ?base class. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Webrev: > >? ? ? > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > >? ? ? ? > >? ? ? >? ? ? >? ? ? > > >? ? ? > >? ? ? >? ? ? >? ? ? > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Let me know what you think, > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?Two initial suggestions: > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?1. FatalOnException should be constructed with a > >? ? ?description > >? ? ? >? ? ?string so > >? ? ? >? ? ? >? ? ?that it can report the failing operation when > calling > >? ? ? >? ? ?FatalError rather > >? ? ? >? ? ? >? ? ?than the general "Problem with a JNI call". > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Agreed with you, the new webrev produces: > >? ? ? >? ? ? > > >? ? ? >? ? ? > FATAL ERROR in native method: GetObjectClass > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? > > > > ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ? >? ? ?Method) > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? > > > > ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? > > ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > and for a return NULL in NewGlobalRef, we would get > >? ? ?automatically: > >? ? ? >? ? ? > > >? ? ? >? ? ? > FATAL ERROR in native method: NewGlobalRef:Return > is NULL > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ? >? ? ?Method) > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Again as we port and simplify more tests (I'll only > do the > >? ? ?locks > >? ? ? >? ? ?for now > >? ? ? >? ? ? > and we can figure out the next steps as start > working on > >? ? ?moving > >? ? ? >? ? ?tests > >? ? ? >? ? ? > out of vmTestbase), > >? ? ? >? ? ? > we can add, if needed, other exception handlers > that don't > >? ? ?throw > >? ? ? >? ? ?or do > >? ? ? >? ? ? > other things depending on the JNI method outputs. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?2. Make the local SafeJNIEnv a pointer called > env so > >? ? ?that the > >? ? ? >? ? ?change is > >? ? ? >? ? ? >? ? ?less disruptive. All the env->op() calls will > remain > >? ? ?and only > >? ? ? >? ? ?the local > >? ? ? >? ? ? >? ? ?error checking will be removed. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Done, I used a unique_ptr to make the object > >? ? ? >? ? ?created/destroyed/available > >? ? ? >? ? ? > as a pointer do-able in one line: > >? ? ? >? ? ? > std::unique_ptr env(new > SafeJNIEnv(jni_env)); > >? ? ? >? ? ? > > >? ? ? >? ? ? > and then you can see that, as you mentioned, the > disruption to > >? ? ? >? ? ?the code > >? ? ? >? ? ? > is much less: > >? ? ? >? ? ? > > >? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > ? > >? ? ? > > > > ? > >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > ? > >? ? ? >? ? ? > > >? ? ? >? ? ? > Basically the tests now become internal to the > SafeJNIEnv > >? ? ?and the > >? ? ? >? ? ?code > >? ? ? >? ? ? > now only contains the JNI calls happening but we > are protected > >? ? ? >? ? ?and will > >? ? ? >? ? ? > fail any test that has an exception or a NULL > return for the > >? ? ? >? ? ?call. Of > >? ? ? >? ? ? > course, this is not 100% proof in terms of not > having any > >? ? ?error > >? ? ? >? ? ?handling > >? ? ? >? ? ? > in the test but in some cases like this, the new > code seems to > >? ? ? >? ? ?just work > >? ? ? >? ? ? > better: > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > ? > >? ? ? > > > > ? > >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > ? > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?The switch from, e.g., checking NULL returns to > >? ? ?checking for > >? ? ? >? ? ?pending > >? ? ? >? ? ? >? ? ?exceptions, need to be sure that the JNI operations > >? ? ?clearly > >? ? ? >? ? ?specify > >? ? ? >? ? ? >? ? ?that > >? ? ? >? ? ? >? ? ?NULL implies there will be an exception > pending. This > >? ? ?change > >? ? ? >? ? ?may be an > >? ? ? >? ? ? >? ? ?issue for static code analysis if not smart > enough to > >? ? ? >? ? ?understand the > >? ? ? >? ? ? >? ? ?RAII wrappers. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Agreed, I fixed it to be more strict and say: in > normal test > >? ? ? >? ? ?handling, > >? ? ? >? ? ? > the JNI calls should never return NULL or throw an > >? ? ?exception. This > >? ? ? >? ? ? > should hold for tests I imagine but if not we can add a > >? ? ?different > >? ? ? >? ? ?call > >? ? ? >? ? ? > verifier as we go. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?Thanks, > >? ? ? >? ? ? >? ? ?David > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Jc > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Let me know what you all think. When talking about it a > >? ? ?bit, I had > >? ? ? >? ? ? > gotten some interest to see what it would look > like. Here > >? ? ?it is > >? ? ? >? ? ?:-). Now > >? ? ? >? ? ? > if it is not wanted like I said, I can backtrack > and just > >? ? ?put the > >? ? ? >? ? ?error > >? ? ? >? ? ? > checks after each JNI call for all the tests as we are > >? ? ?porting them. > >? ? ? >? ? ? > Jc > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > -- > >? ? ? > > >? ? ? > Thanks, > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From sharath.ballal at oracle.com Mon Sep 24 03:49:23 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 23 Sep 2018 20:49:23 -0700 (PDT) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Message-ID: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> Hi, Pls review this test fix to add "-Xmx512m" to SA tests which create either core file or heap dump, to avoid timeout due to large heap sizes. Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ SA tests passed on Mach5 run. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From fairoz.matte at oracle.com Mon Sep 24 13:51:49 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Mon, 24 Sep 2018 06:51:49 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: References: Message-ID: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> Hi Jini, > -----Original Message----- > From: Jini George > Sent: Friday, September 21, 2018 4:07 PM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core > > Hi Fairoz, > > This looks good to me. One nit which got missed out in the original change > also is that in saproc.cpp, the following comments > > 452 > 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 > > 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later > 477 /*ARGSUSED*/ > I have incorporated above changes > would not be required anymore. And we would not need the wrapper to the > callback routine fill_cframe_list() -- as in, we would need only one routine > with the appropriate arguments passed. But you are free to ignore this since > this was not done as a part of the original change. Removed wrapper_fill_cframe_list function and fill_cframe_list function has been used directly. Please find the updated webrev http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ Thanks, Fairoz > > Thanks, > Jini (Not a Reviewer). > > > > On 9/20/2018 7:06 PM, Fairoz Matte wrote: > > Hi, > > > > Kindly review the backport of "JDK-8164383 : jhsdb dumps core on > > Solaris 12 when loading dumped core" to 8u > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 > > > > JDK9 changeset - > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 > > > > JDK9 review thread - > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-October > > /020543.html > > > > Thanks, > > Fairoz > > From jcbeyler at google.com Mon Sep 24 16:16:15 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 09:16:15 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> Message-ID: Thanks Alex! Could I get a second review/LGTM ? Thanks for your help! Jc On Fri, Sep 21, 2018 at 5:22 PM Alex Menkov wrote: > LGTM. > > --alex > > On 09/21/2018 17:06, JC Beyler wrote: > > Hi Alex, > > > > Good catch, it was not done on purpose but now fixed: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.03/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > > > Let me know if this works for you and thanks for the review, > > Jc > > > > On Fri, Sep 21, 2018 at 3:44 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > overall looks good (no changes in the logging) > > except > > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp > > > > : > > - if ((strcmp(name, expMeth) == 0) && > > - (strcmp(sig, expSig) == 0)) { > > - NSK_DISPLAY4("===== %s event received for the tested > method:\n\ > > -\tID=0x%p name=\"%s\" signature=\"%s\"\n", > > + if ((strcmp(name, expMeth) == 0) && (strcmp(sig, expSig) == 0)) > { > > + NSK_DISPLAY4( > > + "%s event received for the tested method:\n" > > + "\tID=0x%p name=\"%s\" signature=\"%s\"\n", > > > > "===== " is dropped from the beginning of the line > > I don't know if this is important. > > > > --alex > > > > > > On 09/21/2018 14:29, JC Beyler wrote: > > > Hi Chris, > > > > > > Done here: > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.02/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > > > > > Anything else? and anybody else motivated to look? > > > > > > Thanks again! > > > Jc > > > > > > On Fri, Sep 21, 2018 at 2:07 PM Chris Plummer > > > > > > >> wrote: > > > > > > Hi JC, > > > > > > Overall looks good. Just a couple minor edits needed: > > > > > > In nativemethbind003.cpp: > > > > > > 158 NSK_DISPLAY1("Inside the registerNative()\nFinding > > class > > > \"%s\" ...\n", CLASS_SIG); > > > > > > This was two lines and you made it one with a \n in the > middle of > > > the string. > > > > > > In ap12t001.cpp: > > > > > > 69 NSK_COMPLAIN2( > > > 70 "Received unexpected number of ObjectFree > > events: > > > %d\n" > > > 71 "\texpected number: %d", > > > 72 obj_free, EXP_OBJ_FREE); > > > > > > There's no \n at the end of this output (and there never was). > > > Normally NSK_COMPLAIN is always used with a terminating \n. > > > > > > thanks, > > > > > > Chris > > > > > > > > > On 9/21/18 1:05 PM, JC Beyler wrote: > > >> Hi Chris, > > >> > > >> Sounds good to me; here it is: > > >> Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ > > > > >> > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 > > >> > > >> I admit I strived to stay consistent and always started a > > new line > > >> for the multi-line argument even if the string was not too > long; > > >> it's a question of style I believe but it felt more readable > to > > >> me. I'll happily change whatever anyone prefers. > > >> > > >> This has passed the vmTestbase tests I changed but due to the > > >> shared changes, I've launched a full vmTestbase testing now. > > >> > > >> Let me know what you think, > > >> Jc > > >> > > >> On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer > > >> > > >> > > wrote: > > >> > > >> On 9/21/18 10:55 AM, JC Beyler wrote: > > >>> Hi Chris, > > >>> > > >>> I hesitated to be honest and then thought that > > debug_str was > > >>> better as you would clearly see that it is a multi-lilne > > >>> string and what parameters are what. But I'll take your > > >>> preference (it's relatively the same for me). Quick > > question > > >>> though: > > >>> > > >>> Do you have a preference between: > > >>> NSK_COMPLAIN6( > > >>> "TEST FAILED: %s field \"%s\" has\n" > > >>> "\tsignature: \"%s\"\n" > > >>> "\tgeneric signature: \"%s\"\n\n" > > >>> "\tExpected: \"%s\"\n" > > >>> "\t\t\"%s\"\n\n", > > >>> (instance==0)?"instance":"static", > > >>> fld_sig[idx][0], > > >>> sign, (gen_sign==NULL)?"NULL":gen_sign, > > >>> fld_sig[idx][2], fld_sig[idx][3]); > > >>> or: > > >>> NSK_COMPLAIN6( > > >>> "TEST FAILED: %s field \"%s\" > > has\n\tsignature: \"%s\"\n" > > >>> "\tgeneric signature: > > \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", > > >>> (instance==0)?"instance":"static", > > >>> fld_sig[idx][0], > > >>> sign, (gen_sign==NULL)?"NULL":gen_sign, > > >>> fld_sig[idx][2], fld_sig[idx][3]); > > >>> I think I like the first because you can clearly see > > what we want to be printed out; but for code vertical > > >>> compression, the second is better. What do you think? > > >> I also prefer the first one. > > >> > > >> thanks, > > >> > > >> Chris > > >>> Thanks! > > >>> Jc > > >>> > > >>> On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer > > >>> > > >> > > >>> wrote: > > >>> > > >>> Hi JC, > > >>> > > >>> I didn't realize you intended to move all the > strings > > >>> into a "const char*" first. Seems unnecessary, and I > > >>> think not as easy to read: > > >>> > > >>> 138 const char* debug_str = > > >>> 139 "TEST FAILED: > JVMTI_EVENT_CLASS_LOAD > > >>> event received for\n" > > >>> 140 "\t a primitive class/array of > > primitive > > >>> types with the signature \"%s\"\n"; > > >>> 141 NSK_COMPLAIN1(debug_str, sig); > > >>> > > >>> vs > > >>> > > >>> 138 NSK_COMPLAIN1("TEST FAILED: > > >>> JVMTI_EVENT_CLASS_LOAD event received for\n" > > >>> 139 "\t a primitive > > class/array of > > >>> primitive types with the signature \"%s\"\n", > > >>> 140 sig); > > >>> > > >>> or > > >>> > > >>> 138 NSK_COMPLAIN1( > > >>> 139 "TEST FAILED: > JVMTI_EVENT_CLASS_LOAD > > >>> event received for\n" > > >>> 140 "\t a primitive class/array of > > primitive > > >>> types with the signature \"%s\"\n", > > >>> 141 sig); > > >>> > > >>> thanks, > > >>> > > >>> Chris > > >>> > > >>> On 9/21/18 8:00 AM, JC Beyler wrote: > > >>>> Hi all, > > >>>> > > >>>> Is anyone motivated on a Friday to review this ? :) > > >>>> > > >>>> It should be fairly straightforward :-) > > >>>> > > >>>> Thanks, > > >>>> Jc > > >>>> > > >>>> On Tue, Sep 18, 2018 at 12:07 PM JC Beyler > > >>>> > > >> wrote: > > >>>> > > >>>> Hi all, > > >>>> > > >>>> Could I have a review for this webrev: > > >>>> > > >>>> Webrev: > > >>>> http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ > > > > >>>> > > > > >>>> Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210689 > > >>>> > > >>>> Let me know what you think, > > >>>> Jc > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> > > >>>> Thanks, > > >>>> Jc > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> Thanks, > > >>> Jc > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Sep 24 16:18:22 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 09:18:22 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> Message-ID: Hi David, Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting for an explicit LGTM from you or from someone else on this list to do a review. Thanks again for your help, Jc On Sun, Sep 23, 2018 at 9:22 AM David Holmes wrote: > Hi Jc, > > I don't think it is an issue for this to go ahead. If the static > analysis tool has an issue then we can either find out how to teach it > about this code structure, or else flag the issues as false positives. > I'd be relying on one of the serviceability team here to handle that if > the problem arises. > > Thanks, > David > > On 23/09/2018 12:17 PM, JC Beyler wrote: > > Hi David, > > > > No worries with the time to answer; I appreciate the review! > > > > That's a fair point. Is it possible to "describe" to the static analysis > > tool to "trust" calls made in the SafeJNIEnv class? > > > > Otherwise, do you have any idea on how to go forward? For what it's > > worth, this current webrev does not try to replace exception checking > > with the SafeJNIEnv (it actually adds it), so for now the > > question/solution could be delayed. I could continue working on this in > > the scope of both the nsk/gc/lock/jniref code base and the NSK_VERIFIER > > macro removal and we can look at how to tackle the cases where the tests > > are actually calling exception checking (I know my heapmonitor does for > > example). > > > > Let me know what you think and thanks for the review, > > Jc > > > > > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > > wrote: > > > > Hi Jc, > > > > Sorry for the delay on getting back to this but I'm travelling at the > > moment. > > > > This looks quite neat. Thanks also to Alex for all the suggestions. > > > > My only remaining concern is that static analysis tools may not like > > this because they may not be able to determine that we won't make > > subsequent JNI calls when an exception happens in the first. That's > not > > a reason not to do this of course, just flagging that we may have to > do > > something to deal with that problem. > > > > Thanks, > > David > > > > On 20/09/2018 11:56 AM, JC Beyler wrote: > > > Hi Alex, > > > > > > Done here, thanks for the review: > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > Thanks again! > > > Jc > > > > > > > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > > > > > > >> wrote: > > > > > > Hi Jc, > > > > > > Looks good to me. > > > A minor note: > > > - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid > > global > > > namespece pollution (ErrorHandler is too generic name). > > > > > > --alex > > > > > > On 09/19/2018 15:56, JC Beyler wrote: > > > > Hi Alex, > > > > > > > > I've updated the webrev to: > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > That webrev has the code that is shown here in snippets. > > > > > > > > > > > > Thanks for the reviews, I've relatively followed your > reviews > > > except for > > > > one detail due to me wanting to handle the NSK_JNI_VERIFY > > macros via > > > > this system as well later down the road. For an example: > > > > > > > > We currently have in the code: > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > NSK_CPP_STUB2(GetObjectClass, > > > > pEnv, mhToCall)) != NULL) ) > > > > > > > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor > > > (JDK-8210728) > > > > to: > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > pEnv->GetObjectClass(pEnv, > > > > mhToCall)) != NULL) ) > > > > > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it > > > becomes via > > > > this wrapping of JNIEnv: > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > > > > > > > > 3) Then, via removing the assignment, we'd arrive to a: > > > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > > > if (!mhClass) > > > > > > > > Without any loss of checking for failures, etc. > > > > > > > > So that is my motivation for most of this work with a > concrete > > > example > > > > (hopefully it helps drive this conversation). > > > > > > > > I inlined my answers here, let me know what you think. > > > > > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > > > > > > > > > > > > > > >>> wrote: > > > > > > > > Hi Jc, > > > > > > > > Updated tests looks good. > > > > Some notes about implementation. > > > > > > > > - FatalOnException implements both verification and > error > > > handling > > > > It would be better to separate them (and this makes > > easy to > > > implement > > > > error handling different from JNIEnv::FatalError). > > > > The simplest way is to define error handler as > > > > class SafeJNIEnv { > > > > public: > > > > typedef void (*ErrorHandler)(JNIEnv *env, const > > char* > > > errorMsg); > > > > // error handler which terminates jvm by using > > FatalError() > > > > static void FatalError(JNIEnv *env, const char > > *errrorMsg); > > > > > > > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler > > errorHandler = > > > > FatalError); > > > > (SafeJNIEnv methods should create FatalOnException > objects > > > passing > > > > errorHandler) > > > > > > > > > > > > > > > > Agreed, I tried to keep the code simple. The concepts you > > talk about > > > > here are generally what I reserve for when I need it (ie > > > extensions and > > > > handling new cases). But a lot are going to be needed soon > > so I > > > think it > > > > is a good time to iron the code out now on this "simple" > > webrev. > > > > > > > > So done for this. > > > > > > > > > > > > > > > > - FatalOnException is used in SafeJNIEnv methods as > > > > FatalOnException marker(this, "msg"); > > > > ret = > > > > (optional)marker.check_for_null(ret); > > > > return ret; > > > > But actually I'd call it something like > > JNICallResultVerifier and > > > > create > > > > the object after JNI call. like > > > > ret = > > > > JNICallResultVerifier(this, "msg") > > > > (optional).notNull(ret); > > > > return ret; > > > > or even (if you like such syntax sugar) you can define > > > > template > > > > T resultNotNull(T result) { > > > > notNull(result); > > > > return result; > > > > } > > > > and do > > > > ret = > > > > return JNICallResultVerifier(this, > > "msg").resultNotNull(ret); > > > > > > > > > > > > So I renamed FatalOnException to now being JNIVerifier. > > > > > > > > Though I like it, I don't think we can do it, except if we > > do it > > > > slightly differently: > > > > I'm trying to solve two problems with one stone: > > > > - How to check for returns of JNI calls in the way > that is > > > done here > > > > - How to remove NSK_JNI_VERIFY* (from > > nsk/share/jni/jni_tools) > > > > > > > > However, the NSK_JNI_VERIFY need to start a tracing system > > before > > > the > > > > call to JNI, so it won't work this way. (Side question > > would be > > > do we > > > > still care about the tracing in NSK_JNI_VERIFY, if we > > don't then > > > your > > > > solution works well in most situations). > > > > > > > > My vision or intuition is that we would throw a template > > at some > > > point > > > > on SafeJNIEnv to handle both cases and have JNIVerifier > > become a > > > > specialization in certain cases and something different > > for the > > > > NSK_JNI_VERIFY case (or have a different constructor to > enable > > > tracing). > > > > But for now, I offer the implementation that does: > > > > > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > > > > JNIVerifier marker(this, "GetObjectClass"); > > > > return > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > > > } > > > > > > > > and: > > > > > > > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID > > field, jobject > > > > value) { > > > > JNIVerifier<> marker(this, "SetObjectField"); > > > > _jni_env->SetObjectField(obj, field, value); > > > > } > > > > > > > > > > > > > > > > > > > > - you added #include in the test (and you > have to > > > add it to > > > > every test). > > > > It would be simpler to add the include to > > SafeJNIEnv.hpp and > > > define > > > > typedef std::unique_ptr SafeJNIEnvPtr; > > > > Then each in the test methods: > > > > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > > > > or you can add > > > > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, > > > ErrorHandler > > > > errorHandler = fatalError) > > > > and get > > > > SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > > > > > > > > > > > > Done, I like that, even less code change to tests then. > > > > > > > > > > > > > > > > - it would be better to wrap internal classes > > > (FatalOnException) into > > > > unnamed namespace - this helps to avoid conflicts with > > other > > > classes) > > > > > > > > - FatalOnException::check_for_null(void* ptr) > > > > should be > > > > FatalOnException::check_for_null(const void* ptr) > > > > And calling the method you don't need reinterpret_cast > > > > > > > > > > > > Also done, it got renamed to ResultNotNull, is using a > > template > > > now, but > > > > agreed, that worked. > > > > Thanks again for the review, > > > > Jc > > > > > > > > > > > > --alex > > > > > > > > > > > > On 09/18/2018 11:07, JC Beyler wrote: > > > > > Hi David, > > > > > > > > > > Thanks for the quick review and thoughts. I have > > now a new > > > > version here > > > > > that addresses your comments: > > > > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > > > > > > > > > > > > > > > > > > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > I've also inlined my answers/comments. > > > > > > > > > > > > > > > > > > > > > I've slowly started working on JDK-8191519 > > > > > > > > . > > > > However before > > > > > > starting to really refactor all the tests, I > > > thought I'd > > > > get a few > > > > > > opinions. I am working on internalizing the > > error > > > handling > > > > of JNI > > > > > calls > > > > > > via a SafeJNIEnv class that redefines all > > the JNI > > > calls to > > > > add an > > > > > error > > > > > > checker. > > > > > > > > > > > > The advantage is that the test code will > > look and > > > feel like > > > > > normal JNI > > > > > > code and calls but will have the checks we > > want to have > > > > for our > > > > > tests. > > > > > > > > > > Not sure I get that. Normal JNI code has to > > check for > > > > errors/exceptions > > > > > after every call. The tests need those checks > too. > > > Today they are > > > > > explicit, with this change they become > > implicit. Not sure > > > > what we are > > > > > gaining here ?? > > > > > > > > > > > > > > > In my humble opinion, having the error checking out > > of the way > > > > allows > > > > > the code reader to concentrate on the JNI code while > > > maintaining > > > > error > > > > > checking. We use something similar internally, so > > perhaps I'm > > > > biased to > > > > > it :-). > > > > > If this is not a desired/helpful "feature" to > simplify > > > tests in > > > > general, > > > > > I will backtrack it and just add the explicit tests > > to the > > > native > > > > code > > > > > of the locks for the fix > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > > > > > > > Let me however try to make my case and let me know > what > > > you all > > > > think! > > > > > > > > > > > > > > > > If agreed with this, we can augment the > > SafeJNIEnv > > > class > > > > as needed. > > > > > > Also, if the tests require something else > > than fatal > > > > errors, we > > > > > can add > > > > > > a different marker and make it a parameter > > to the > > > base class. > > > > > > > > > > > > Webrev: > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > > > Let me know what you think, > > > > > > > > > > Two initial suggestions: > > > > > > > > > > 1. FatalOnException should be constructed with a > > > description > > > > string so > > > > > that it can report the failing operation when > > calling > > > > FatalError rather > > > > > than the general "Problem with a JNI call". > > > > > > > > > > > > > > > Agreed with you, the new webrev produces: > > > > > > > > > > FATAL ERROR in native method: GetObjectClass > > > > > at > > > > > > > > > > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > > > > at > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > Method) > > > > > at > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > at > > > > > > > > > > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > > > > at > > > > > > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > > > > > > > > > > and for a return NULL in NewGlobalRef, we would get > > > automatically: > > > > > > > > > > FATAL ERROR in native method: NewGlobalRef:Return > > is NULL > > > > > at > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > Method) > > > > > > > > > > at > > > > > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > > > > > > > > > > > > > > > > Again as we port and simplify more tests (I'll only > > do the > > > locks > > > > for now > > > > > and we can figure out the next steps as start > > working on > > > moving > > > > tests > > > > > out of vmTestbase), > > > > > we can add, if needed, other exception handlers > > that don't > > > throw > > > > or do > > > > > other things depending on the JNI method outputs. > > > > > > > > > > > > > > > 2. Make the local SafeJNIEnv a pointer called > > env so > > > that the > > > > change is > > > > > less disruptive. All the env->op() calls will > > remain > > > and only > > > > the local > > > > > error checking will be removed. > > > > > > > > > > > > > > > Done, I used a unique_ptr to make the object > > > > created/destroyed/available > > > > > as a pointer do-able in one line: > > > > > std::unique_ptr env(new > > SafeJNIEnv(jni_env)); > > > > > > > > > > and then you can see that, as you mentioned, the > > disruption to > > > > the code > > > > > is much less: > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > Basically the tests now become internal to the > > SafeJNIEnv > > > and the > > > > code > > > > > now only contains the JNI calls happening but we > > are protected > > > > and will > > > > > fail any test that has an exception or a NULL > > return for the > > > > call. Of > > > > > course, this is not 100% proof in terms of not > > having any > > > error > > > > handling > > > > > in the test but in some cases like this, the new > > code seems to > > > > just work > > > > > better: > > > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > > > > > The switch from, e.g., checking NULL returns to > > > checking for > > > > pending > > > > > exceptions, need to be sure that the JNI > operations > > > clearly > > > > specify > > > > > that > > > > > NULL implies there will be an exception > > pending. This > > > change > > > > may be an > > > > > issue for static code analysis if not smart > > enough to > > > > understand the > > > > > RAII wrappers. > > > > > > > > > > > > > > > Agreed, I fixed it to be more strict and say: in > > normal test > > > > handling, > > > > > the JNI calls should never return NULL or throw an > > > exception. This > > > > > should hold for tests I imagine but if not we can > add a > > > different > > > > call > > > > > verifier as we go. > > > > > > > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > Let me know what you all think. When talking about > it a > > > bit, I had > > > > > gotten some interest to see what it would look > > like. Here > > > it is > > > > :-). Now > > > > > if it is not wanted like I said, I can backtrack > > and just > > > put the > > > > error > > > > > checks after each JNI call for all the tests as we > are > > > porting them. > > > > > Jc > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Sep 24 16:28:09 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 09:28:09 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti Message-ID: Hi all, As the tests have become C++ tests, the NSK_CPP_STUBS are no longer needed. I did two awk scripts to remove them and will be rolling them out in 50 file max reviews to streamline the reviews for the reviewers. So here is the first which handles all the cases outside of the jvmti subfolder: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 The bug contains information on the two scripts I used. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Mon Sep 24 17:25:31 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 24 Sep 2018 10:25:31 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> Message-ID: Hi Alex and Gary, Please review the updated patch that includes suggested changes. http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil ?On 9/21/18, 3:59 PM, "Alex Menkov" wrote: One more note: please add "@Override" annotation to the SocketListeningConnector.updateArgumentMapIfRequired --alex On 09/21/2018 02:26, gary.adams at oracle.com wrote: > Looks good to me. > > For the javadoc > > 72 *

> 73 * If arguments contains addressing information. and > 74 * only one connection will be accepted, the {@link #accept accept} method > 75 * can be called immediately without calling this method. > 76 * > 77 * If the addressing information provided in arguments > implies > 78 * the auto detection this information might be updated with the address > 79 * of the started listener. > > - you could add a

tag if you want to maintain the spacing in the > generated javadoc. > - I've seen other changesets migrating to {@code ..} from the older > ... > > It would be good to include some negative testing. > Not sure if it is already covered in other tests, e.g. > > args1 = defaultArguments() > startListening(args1) // bound port updated > startListening(args1) // already listening > > > On 9/20/18 10:59 PM, Daniil Titov wrote: >> Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. >> >> When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However, the consequent call of startListening() methods with unspecified port number fails rather than starts a new listener on auto detected port. This happens since the original argument map passed to the startListening() methods is used as a key to store the mapping to the started listeners. >> >> The fix ensures that in cases when the port is auto detected the argument map is updated with the bound port number. >> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >> >> Thanks! >> --Daniil >> >> >> > From gary.adams at oracle.com Mon Sep 24 17:39:38 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 24 Sep 2018 13:39:38 -0400 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> Message-ID: <5BA9215A.20209@oracle.com> Looks good to me. On 9/24/18, 1:25 PM, Daniil Titov wrote: > Hi Alex and Gary, > > Please review the updated patch that includes suggested changes. > > http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > > > ?On 9/21/18, 3:59 PM, "Alex Menkov" wrote: > > One more note: > please add "@Override" annotation to the > SocketListeningConnector.updateArgumentMapIfRequired > > --alex > > On 09/21/2018 02:26, gary.adams at oracle.com wrote: > > Looks good to me. > > > > For the javadoc > > > > 72 *

> > 73 * Ifarguments contains addressing information. and > > 74 * only one connection will be accepted, the {@link #accept accept} method > > 75 * can be called immediately without calling this method. > > 76 * > > 77 * If the addressing information provided inarguments > > implies > > 78 * the auto detection this information might be updated with the address > > 79 * of the started listener. > > > > - you could add a

tag if you want to maintain the spacing in the > > generated javadoc. > > - I've seen other changesets migrating to {@code ..} from the older > > ... > > > > It would be good to include some negative testing. > > Not sure if it is already covered in other tests, e.g. > > > > args1 = defaultArguments() > > startListening(args1) // bound port updated > > startListening(args1) // already listening > > > > > > On 9/20/18 10:59 PM, Daniil Titov wrote: > >> Please review the change that fixes the issue in com.sun.tools.jdi.SocketListenerConnector.startListening() method. > >> > >> When the argument map passed to startListening() methods has the port number unspecified or set to zero the port is auto detected. However, the consequent call of startListening() methods with unspecified port number fails rather than starts a new listener on auto detected port. This happens since the original argument map passed to the startListening() methods is used as a key to store the mapping to the started listeners. > >> > >> The fix ensures that in cases when the port is auto detected the argument map is updated with the bound port number. > >> > >> Mach5 vmTestbase_nsk_jdi tests successfully passed. > >> > >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > >> > >> Thanks! > >> --Daniil > >> > >> > >> > > > > > From chris.plummer at oracle.com Mon Sep 24 17:52:24 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 24 Sep 2018 10:52:24 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> Message-ID: <6b9cc94c-6cdb-5ebd-68ea-00fd6da3fd2f@oracle.com> An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Sep 24 18:40:54 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 24 Sep 2018 11:40:54 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: References: Message-ID: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> (cc-ing hotspot-dev alias) Hi Jc, the fix looks good to me. don't forget to clean up nsk/share/jni/README at the end. Thanks, -- Igor > On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: > > Hi all, > > As the tests have become C++ tests, the NSK_CPP_STUBS are no longer needed. I did two awk scripts to remove them and will be rolling them out in 50 file max reviews to streamline the reviews for the reviewers. > > So here is the first which handles all the cases outside of the jvmti subfolder: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 > > The bug contains information on the two scripts I used. > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Sep 24 21:17:03 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 14:17:03 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> Message-ID: Thanks Igor, I added https://bugs.openjdk.java.net/browse/JDK-8211072 to not forget it. Thanks again! Jc On Mon, Sep 24, 2018 at 11:40 AM Igor Ignatyev wrote: > (cc-ing hotspot-dev alias) > > Hi Jc, > > the fix looks good to me. don't forget to clean up nsk/share/jni/README at > the end. > > Thanks, > -- Igor > > On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: > > Hi all, > > As the tests have become C++ tests, the NSK_CPP_STUBS are no longer > needed. I did two awk scripts to remove them and will be rolling them out > in 50 file max reviews to streamline the reviews for the reviewers. > > So here is the first which handles all the cases outside of the jvmti > subfolder: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 > > The bug contains information on the two scripts I used. > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Sep 24 21:30:22 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 24 Sep 2018 14:30:22 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <5BA9215A.20209@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> Message-ID: <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> +1 --alex On 09/24/2018 10:39, Gary Adams wrote: > Looks good to me. > > On 9/24/18, 1:25 PM, Daniil Titov wrote: >> Hi Alex and Gary, >> >> Please review the updated patch that includes suggested changes. >> >> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >> >> Thanks! >> --Daniil >> >> >> >> >> ?On 9/21/18, 3:59 PM, "Alex Menkov"? wrote: >> >> ???? One more note: >> ???? please add "@Override" annotation to the >> ???? SocketListeningConnector.updateArgumentMapIfRequired >> >> ???? --alex >> >> ???? On 09/21/2018 02:26, gary.adams at oracle.com wrote: >> ???? >? Looks good to me. >> ???? > >> ???? >? For the javadoc >> ???? > >> ???? >???? 72????? *

>> ???? >???? 73????? * Ifarguments? contains addressing >> information. and >> ???? >???? 74????? * only one connection will be accepted, the {@link >> #accept accept} method >> ???? >???? 75????? * can be called immediately without calling this >> method. >> ???? >???? 76????? * >> ???? >? 77 * If the addressing information provided >> inarguments >> ???? >? implies >> ???? >? 78 * the auto detection this information might be updated with >> the address >> ???? >? 79 * of the started listener. >> ???? > >> ???? >???? - you could add a

? tag if you want to maintain the >> spacing in the >> ???? >? generated javadoc. >> ???? >???? - I've seen other changesets migrating to {@code ..} from >> the older >> ???? >? ... >> ???? > >> ???? >? It would be good to include some negative testing. >> ???? >? Not sure if it is already covered in other tests, e.g. >> ???? > >> ???? >?????? args1 = defaultArguments() >> ???? >?????? startListening(args1)?? // bound port updated >> ???? >?????? startListening(args1)?? // already listening >> ???? > >> ???? > >> ???? >? On 9/20/18 10:59 PM, Daniil Titov wrote: >> ???? >>? Please review the change that fixes the issue in >> com.sun.tools.jdi.SocketListenerConnector.startListening() method. >> ???? >> >> ???? >>? When the argument map passed to startListening() methods has >> the port number unspecified or set to zero the port is auto detected. >> However,? the consequent call of startListening() methods with >> unspecified port number fails rather than starts a new listener on >> auto detected port. This happens since the original argument map >> passed to the startListening() methods is used as a key to store the >> mapping to the started listeners. >> ???? >> >> ???? >>? The fix ensures that in cases when the port is auto detected >> the argument map is updated with the bound port number. >> ???? >> >> ???? >>? Mach5 vmTestbase_nsk_jdi tests successfully passed. >> ???? >> >> ???? >>? Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >> ???? >>? Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >> ???? >> >> ???? >>? Thanks! >> ???? >>? --Daniil >> ???? >> >> ???? >> >> ???? >> >> ???? > >> >> >> > From jcbeyler at google.com Mon Sep 24 21:30:10 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 14:30:10 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: <6b9cc94c-6cdb-5ebd-68ea-00fd6da3fd2f@oracle.com> References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> <6b9cc94c-6cdb-5ebd-68ea-00fd6da3fd2f@oracle.com> Message-ID: Thanks Chris! Because you saw that, I double checked and actually saw a few more so I'm just showing the incremental here for your information: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.03_04/ (The full is here: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.04/) I've restarted a manual test and will submit if it passes. Thanks for the review! Jc On Mon, Sep 24, 2018 at 10:52 AM Chris Plummer wrote: > Hi JC, > > I went to check the change I suggested in nativemethbind003.cpp and found > another line with a \n in the middle: > > 129 NSK_COMPLAIN5( > 130 "TEST FAILED: wrong NativeMethodBind events\n\tfor tested > method \"%s %s\" bound with \"%s\":\n" > 131 "\tgot: %d\texpected: %d\n\n", > > Also ap01t001.cpp has the same missing \n that ap01t012.cpp had: > > 69 NSK_COMPLAIN2( > 70 "Received unexpected number of ObjectFree events: %d\n" > 71 "\texpected number: %d", > 72 obj_free, (EXP_OBJ_NUMBER - 1)); > > Otherwise looks good. I don't need to see another review. > > thanks, > > Chris > > On 9/24/18 9:16 AM, JC Beyler wrote: > > Thanks Alex! > > Could I get a second review/LGTM ? > > Thanks for your help! > Jc > > On Fri, Sep 21, 2018 at 5:22 PM Alex Menkov > wrote: > >> LGTM. >> >> --alex >> >> On 09/21/2018 17:06, JC Beyler wrote: >> > Hi Alex, >> > >> > Good catch, it was not done on purpose but now fixed: >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.03/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >> > >> > Let me know if this works for you and thanks for the review, >> > Jc >> > >> > On Fri, Sep 21, 2018 at 3:44 PM Alex Menkov > > > wrote: >> > >> > Hi Jc, >> > >> > overall looks good (no changes in the logging) >> > except >> > >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t003/hs201t003.cpp >> > >> > : >> > - if ((strcmp(name, expMeth) == 0) && >> > - (strcmp(sig, expSig) == 0)) { >> > - NSK_DISPLAY4("===== %s event received for the tested >> method:\n\ >> > -\tID=0x%p name=\"%s\" signature=\"%s\"\n", >> > + if ((strcmp(name, expMeth) == 0) && (strcmp(sig, expSig) == >> 0)) { >> > + NSK_DISPLAY4( >> > + "%s event received for the tested method:\n" >> > + "\tID=0x%p name=\"%s\" signature=\"%s\"\n", >> > >> > "===== " is dropped from the beginning of the line >> > I don't know if this is important. >> > >> > --alex >> > >> > >> > On 09/21/2018 14:29, JC Beyler wrote: >> > > Hi Chris, >> > > >> > > Done here: >> > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.02/ >> > >> > > >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >> > > >> > > Anything else? and anybody else motivated to look? >> > > >> > > Thanks again! >> > > Jc >> > > >> > > On Fri, Sep 21, 2018 at 2:07 PM Chris Plummer >> > >> > > > > >> wrote: >> > > >> > > Hi JC, >> > > >> > > Overall looks good. Just a couple minor edits needed: >> > > >> > > In nativemethbind003.cpp: >> > > >> > > 158 NSK_DISPLAY1("Inside the registerNative()\nFinding >> > class >> > > \"%s\" ...\n", CLASS_SIG); >> > > >> > > This was two lines and you made it one with a \n in the >> middle of >> > > the string. >> > > >> > > In ap12t001.cpp: >> > > >> > > 69 NSK_COMPLAIN2( >> > > 70 "Received unexpected number of ObjectFree >> > events: >> > > %d\n" >> > > 71 "\texpected number: %d", >> > > 72 obj_free, EXP_OBJ_FREE); >> > > >> > > There's no \n at the end of this output (and there never >> was). >> > > Normally NSK_COMPLAIN is always used with a terminating \n. >> > > >> > > thanks, >> > > >> > > Chris >> > > >> > > >> > > On 9/21/18 1:05 PM, JC Beyler wrote: >> > >> Hi Chris, >> > >> >> > >> Sounds good to me; here it is: >> > >> Webrev: >> > http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.01/ >> > >> > >> >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210689 >> > >> >> > >> I admit I strived to stay consistent and always started a >> > new line >> > >> for the multi-line argument even if the string was not too >> long; >> > >> it's a question of style I believe but it felt more >> readable to >> > >> me. I'll happily change whatever anyone prefers. >> > >> >> > >> This has passed the vmTestbase tests I changed but due to >> the >> > >> shared changes, I've launched a full vmTestbase testing now. >> > >> >> > >> Let me know what you think, >> > >> Jc >> > >> >> > >> On Fri, Sep 21, 2018 at 10:59 AM Chris Plummer >> > >> >> > > >>> >> > wrote: >> > >> >> > >> On 9/21/18 10:55 AM, JC Beyler wrote: >> > >>> Hi Chris, >> > >>> >> > >>> I hesitated to be honest and then thought that >> > debug_str was >> > >>> better as you would clearly see that it is a >> multi-lilne >> > >>> string and what parameters are what. But I'll take your >> > >>> preference (it's relatively the same for me). Quick >> > question >> > >>> though: >> > >>> >> > >>> Do you have a preference between: >> > >>> NSK_COMPLAIN6( >> > >>> "TEST FAILED: %s field \"%s\" has\n" >> > >>> "\tsignature: \"%s\"\n" >> > >>> "\tgeneric signature: \"%s\"\n\n" >> > >>> "\tExpected: \"%s\"\n" >> > >>> "\t\t\"%s\"\n\n", >> > >>> (instance==0)?"instance":"static", >> > >>> fld_sig[idx][0], >> > >>> sign, >> (gen_sign==NULL)?"NULL":gen_sign, >> > >>> fld_sig[idx][2], fld_sig[idx][3]); >> > >>> or: >> > >>> NSK_COMPLAIN6( >> > >>> "TEST FAILED: %s field \"%s\" >> > has\n\tsignature: \"%s\"\n" >> > >>> "\tgeneric signature: >> > \"%s\"\n\n\tExpected: \"%s\"\n\t\t\"%s\"\n\n", >> > >>> (instance==0)?"instance":"static", >> > >>> fld_sig[idx][0], >> > >>> sign, >> (gen_sign==NULL)?"NULL":gen_sign, >> > >>> fld_sig[idx][2], fld_sig[idx][3]); >> > >>> I think I like the first because you can clearly see >> > what we want to be printed out; but for code vertical >> > >>> compression, the second is better. What do you think? >> > >> I also prefer the first one. >> > >> >> > >> thanks, >> > >> >> > >> Chris >> > >>> Thanks! >> > >>> Jc >> > >>> >> > >>> On Fri, Sep 21, 2018 at 10:16 AM Chris Plummer >> > >>> > > > > >> >> > >>> wrote: >> > >>> >> > >>> Hi JC, >> > >>> >> > >>> I didn't realize you intended to move all the >> strings >> > >>> into a "const char*" first. Seems unnecessary, and >> I >> > >>> think not as easy to read: >> > >>> >> > >>> 138 const char* debug_str = >> > >>> 139 "TEST FAILED: >> JVMTI_EVENT_CLASS_LOAD >> > >>> event received for\n" >> > >>> 140 "\t a primitive class/array of >> > primitive >> > >>> types with the signature \"%s\"\n"; >> > >>> 141 NSK_COMPLAIN1(debug_str, sig); >> > >>> >> > >>> vs >> > >>> >> > >>> 138 NSK_COMPLAIN1("TEST FAILED: >> > >>> JVMTI_EVENT_CLASS_LOAD event received for\n" >> > >>> 139 "\t a primitive >> > class/array of >> > >>> primitive types with the signature \"%s\"\n", >> > >>> 140 sig); >> > >>> >> > >>> or >> > >>> >> > >>> 138 NSK_COMPLAIN1( >> > >>> 139 "TEST FAILED: >> JVMTI_EVENT_CLASS_LOAD >> > >>> event received for\n" >> > >>> 140 "\t a primitive class/array of >> > primitive >> > >>> types with the signature \"%s\"\n", >> > >>> 141 sig); >> > >>> >> > >>> thanks, >> > >>> >> > >>> Chris >> > >>> >> > >>> On 9/21/18 8:00 AM, JC Beyler wrote: >> > >>>> Hi all, >> > >>>> >> > >>>> Is anyone motivated on a Friday to review this ? >> :) >> > >>>> >> > >>>> It should be fairly straightforward :-) >> > >>>> >> > >>>> Thanks, >> > >>>> Jc >> > >>>> >> > >>>> On Tue, Sep 18, 2018 at 12:07 PM JC Beyler >> > >>>> >> > >> wrote: >> > >>>> >> > >>>> Hi all, >> > >>>> >> > >>>> Could I have a review for this webrev: >> > >>>> >> > >>>> Webrev: >> > >>>> http://cr.openjdk.java.net/~jcbeyler/8210689/webrev.00/ >> > >> > >>>> >> > >> > >>>> Bug: >> > https://bugs.openjdk.java.net/browse/JDK-8210689 >> > >>>> >> > >>>> Let me know what you think, >> > >>>> Jc >> > >>>> >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> >> > >>>> Thanks, >> > >>>> Jc >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> >> > >>> Thanks, >> > >>> Jc >> > >> >> > >> >> > >> >> > >> >> > >> -- >> > >> >> > >> Thanks, >> > >> Jc >> > > >> > > >> > > >> > > >> > > -- >> > > >> > > Thanks, >> > > Jc >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Sep 24 21:56:34 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 24 Sep 2018 14:56:34 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> Message-ID: <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> Daniil, Just remembered that SQE requested to not add new tests to vmTestbase (see test/hotspot/jtreg/vmTestbase/README.md) Could you please move the test to correct location (I suppose it's test/jdk/com/sun/jdi) --alex On 09/24/2018 14:30, Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 10:39, Gary Adams wrote: >> Looks good to me. >> >> On 9/24/18, 1:25 PM, Daniil Titov wrote: >>> Hi Alex and Gary, >>> >>> Please review the updated patch that includes suggested changes. >>> >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >>> Thanks! >>> --Daniil >>> >>> >>> >>> >>> ?On 9/21/18, 3:59 PM, "Alex Menkov"? wrote: >>> >>> ???? One more note: >>> ???? please add "@Override" annotation to the >>> ???? SocketListeningConnector.updateArgumentMapIfRequired >>> >>> ???? --alex >>> >>> ???? On 09/21/2018 02:26, gary.adams at oracle.com wrote: >>> ???? >? Looks good to me. >>> ???? > >>> ???? >? For the javadoc >>> ???? > >>> ???? >???? 72????? *

>>> ???? >???? 73????? * Ifarguments? contains addressing >>> information. and >>> ???? >???? 74????? * only one connection will be accepted, the {@link >>> #accept accept} method >>> ???? >???? 75????? * can be called immediately without calling this >>> method. >>> ???? >???? 76????? * >>> ???? >? 77 * If the addressing information provided >>> inarguments >>> ???? >? implies >>> ???? >? 78 * the auto detection this information might be updated >>> with the address >>> ???? >? 79 * of the started listener. >>> ???? > >>> ???? >???? - you could add a

? tag if you want to maintain the >>> spacing in the >>> ???? >? generated javadoc. >>> ???? >???? - I've seen other changesets migrating to {@code ..} from >>> the older >>> ???? >? ... >>> ???? > >>> ???? >? It would be good to include some negative testing. >>> ???? >? Not sure if it is already covered in other tests, e.g. >>> ???? > >>> ???? >?????? args1 = defaultArguments() >>> ???? >?????? startListening(args1)?? // bound port updated >>> ???? >?????? startListening(args1)?? // already listening >>> ???? > >>> ???? > >>> ???? >? On 9/20/18 10:59 PM, Daniil Titov wrote: >>> ???? >>? Please review the change that fixes the issue in >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. >>> ???? >> >>> ???? >>? When the argument map passed to startListening() methods has >>> the port number unspecified or set to zero the port is auto detected. >>> However,? the consequent call of startListening() methods with >>> unspecified port number fails rather than starts a new listener on >>> auto detected port. This happens since the original argument map >>> passed to the startListening() methods is used as a key to store the >>> mapping to the started listeners. >>> ???? >> >>> ???? >>? The fix ensures that in cases when the port is auto detected >>> the argument map is updated with the bound port number. >>> ???? >> >>> ???? >>? Mach5 vmTestbase_nsk_jdi tests successfully passed. >>> ???? >> >>> ???? >>? Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >>> ???? >>? Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >>> ???? >> >>> ???? >>? Thanks! >>> ???? >>? --Daniil >>> ???? >> >>> ???? >> >>> ???? >> >>> ???? > >>> >>> >>> >> From chris.plummer at oracle.com Mon Sep 24 22:37:11 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 24 Sep 2018 15:37:11 -0700 Subject: RFR (M) 8210689: Remove the multi-line old C style for string literals In-Reply-To: References: <6903f740-fd14-bc7e-dc10-b15b341d6133@oracle.com> <68fb6884-6d72-e648-e571-208ed21d4565@oracle.com> <8a6e425e-4492-a1de-5976-016524653e9e@oracle.com> <6b9cc94c-6cdb-5ebd-68ea-00fd6da3fd2f@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Sep 25 00:53:24 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 24 Sep 2018 17:53:24 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> Message-ID: Hi Alex, Please review the updated webrev that has new test moved to test/jdk/comsun/jdi/connect folder. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil ?On 9/24/18, 2:56 PM, "Alex Menkov" wrote: Daniil, Just remembered that SQE requested to not add new tests to vmTestbase (see test/hotspot/jtreg/vmTestbase/README.md) Could you please move the test to correct location (I suppose it's test/jdk/com/sun/jdi) --alex On 09/24/2018 14:30, Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 10:39, Gary Adams wrote: >> Looks good to me. >> >> On 9/24/18, 1:25 PM, Daniil Titov wrote: >>> Hi Alex and Gary, >>> >>> Please review the updated patch that includes suggested changes. >>> >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >>> Thanks! >>> --Daniil >>> >>> >>> >>> >>> ?On 9/21/18, 3:59 PM, "Alex Menkov" wrote: >>> >>> One more note: >>> please add "@Override" annotation to the >>> SocketListeningConnector.updateArgumentMapIfRequired >>> >>> --alex >>> >>> On 09/21/2018 02:26, gary.adams at oracle.com wrote: >>> > Looks good to me. >>> > >>> > For the javadoc >>> > >>> > 72 *

>>> > 73 * Ifarguments contains addressing >>> information. and >>> > 74 * only one connection will be accepted, the {@link >>> #accept accept} method >>> > 75 * can be called immediately without calling this >>> method. >>> > 76 * >>> > 77 * If the addressing information provided >>> inarguments >>> > implies >>> > 78 * the auto detection this information might be updated >>> with the address >>> > 79 * of the started listener. >>> > >>> > - you could add a

tag if you want to maintain the >>> spacing in the >>> > generated javadoc. >>> > - I've seen other changesets migrating to {@code ..} from >>> the older >>> > ... >>> > >>> > It would be good to include some negative testing. >>> > Not sure if it is already covered in other tests, e.g. >>> > >>> > args1 = defaultArguments() >>> > startListening(args1) // bound port updated >>> > startListening(args1) // already listening >>> > >>> > >>> > On 9/20/18 10:59 PM, Daniil Titov wrote: >>> >> Please review the change that fixes the issue in >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. >>> >> >>> >> When the argument map passed to startListening() methods has >>> the port number unspecified or set to zero the port is auto detected. >>> However, the consequent call of startListening() methods with >>> unspecified port number fails rather than starts a new listener on >>> auto detected port. This happens since the original argument map >>> passed to the startListening() methods is used as a key to store the >>> mapping to the started listeners. >>> >> >>> >> The fix ensures that in cases when the port is auto detected >>> the argument map is updated with the bound port number. >>> >> >>> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. >>> >> >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> > >>> >>> >>> >> From jcbeyler at google.com Tue Sep 25 03:46:56 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 20:46:56 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> Message-ID: Hi Daniil, Still looks good to me :) Nit: empty line 83 of the new test is not required! Jc On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov wrote: > Hi Alex, > > Please review the updated webrev that has new test moved to > test/jdk/comsun/jdi/connect folder. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > ?On 9/24/18, 2:56 PM, "Alex Menkov" wrote: > > Daniil, > > Just remembered that SQE requested to not add new tests to vmTestbase > (see test/hotspot/jtreg/vmTestbase/README.md) > Could you please move the test to correct location (I suppose it's > test/jdk/com/sun/jdi) > > --alex > > > On 09/24/2018 14:30, Alex Menkov wrote: > > +1 > > > > --alex > > > > On 09/24/2018 10:39, Gary Adams wrote: > >> Looks good to me. > >> > >> On 9/24/18, 1:25 PM, Daniil Titov wrote: > >>> Hi Alex and Gary, > >>> > >>> Please review the updated patch that includes suggested changes. > >>> > >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > >>> > >>> Thanks! > >>> --Daniil > >>> > >>> > >>> > >>> > >>> ?On 9/21/18, 3:59 PM, "Alex Menkov" > wrote: > >>> > >>> One more note: > >>> please add "@Override" annotation to the > >>> SocketListeningConnector.updateArgumentMapIfRequired > >>> > >>> --alex > >>> > >>> On 09/21/2018 02:26, gary.adams at oracle.com wrote: > >>> > Looks good to me. > >>> > > >>> > For the javadoc > >>> > > >>> > 72 *

> >>> > 73 * Ifarguments contains addressing > >>> information. and > >>> > 74 * only one connection will be accepted, the > {@link > >>> #accept accept} method > >>> > 75 * can be called immediately without calling > this > >>> method. > >>> > 76 * > >>> > 77 * If the addressing information provided > >>> inarguments > >>> > implies > >>> > 78 * the auto detection this information might be updated > >>> with the address > >>> > 79 * of the started listener. > >>> > > >>> > - you could add a

tag if you want to maintain the > >>> spacing in the > >>> > generated javadoc. > >>> > - I've seen other changesets migrating to {@code ..} > from > >>> the older > >>> > ... > >>> > > >>> > It would be good to include some negative testing. > >>> > Not sure if it is already covered in other tests, e.g. > >>> > > >>> > args1 = defaultArguments() > >>> > startListening(args1) // bound port updated > >>> > startListening(args1) // already listening > >>> > > >>> > > >>> > On 9/20/18 10:59 PM, Daniil Titov wrote: > >>> >> Please review the change that fixes the issue in > >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. > >>> >> > >>> >> When the argument map passed to startListening() methods > has > >>> the port number unspecified or set to zero the port is auto > detected. > >>> However, the consequent call of startListening() methods with > >>> unspecified port number fails rather than starts a new listener on > >>> auto detected port. This happens since the original argument map > >>> passed to the startListening() methods is used as a key to store > the > >>> mapping to the started listeners. > >>> >> > >>> >> The fix ensures that in cases when the port is auto > detected > >>> the argument map is updated with the bound port number. > >>> >> > >>> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. > >>> >> > >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > >>> >> Webrev: > http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > >>> >> > >>> >> Thanks! > >>> >> --Daniil > >>> >> > >>> >> > >>> >> > >>> > > >>> > >>> > >>> > >> > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Sep 25 10:17:45 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 25 Sep 2018 15:47:45 +0530 Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> References: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> Message-ID: <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> Hi Fairoz, I took a better look at the changes and I realized that the cleanup related to SOLARIS_11_B159_OR_LATER would be valid for only JDK9 and later. Since JDK8 is supported for Solaris 10 too, I believe that the cleanup related changes done as a part of JDK-8164383 should not be done for JDK-8. Thanks! Jini. On 9/24/2018 7:21 PM, Fairoz Matte wrote: > Hi Jini, > >> -----Original Message----- >> From: Jini George >> Sent: Friday, September 21, 2018 4:07 PM >> To: Fairoz Matte ; serviceability- >> dev at openjdk.java.net >> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 >> when loading dumped core >> >> Hi Fairoz, >> >> This looks good to me. One nit which got missed out in the original change >> also is that in saproc.cpp, the following comments >> >> 452 >> 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 >> >> 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later >> 477 /*ARGSUSED*/ >> > > I have incorporated above changes > >> would not be required anymore. And we would not need the wrapper to the >> callback routine fill_cframe_list() -- as in, we would need only one routine >> with the appropriate arguments passed. But you are free to ignore this since >> this was not done as a part of the original change. > > Removed wrapper_fill_cframe_list function and fill_cframe_list function has been used directly. > > Please find the updated webrev > http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ > > Thanks, > Fairoz > >> >> Thanks, >> Jini (Not a Reviewer). >> >> >> >> On 9/20/2018 7:06 PM, Fairoz Matte wrote: >>> Hi, >>> >>> Kindly review the backport of "JDK-8164383 : jhsdb dumps core on >>> Solaris 12 when loading dumped core" to 8u >>> >>> Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ >>> >>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 >>> >>> JDK9 changeset - >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 >>> >>> JDK9 review thread - >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-October >>> /020543.html >>> >>> Thanks, >>> Fairoz >>> From daniel.daugherty at oracle.com Tue Sep 25 15:11:18 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Sep 2018 11:11:18 -0400 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> Message-ID: <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> Adding serviceability-dev at ... since this is JVM/TI... Dan On 9/25/18 10:48 AM, Doug Simon wrote: > A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. > > The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, > skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. > > The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: > * Returning null instead of throwing an exception on failure. > * Adding a `bool null_on_fail` argument to all relevant methods. > * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. > This represents a significant number of changes. > > Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. > > The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. > THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 > > -Doug From daniil.x.titov at oracle.com Tue Sep 25 17:32:09 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 25 Sep 2018 10:32:09 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> Message-ID: <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> HI JC, The webrev is updated to address this. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: JC Beyler Date: Monday, September 24, 2018 at 8:47 PM To: Cc: , , Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Hi Daniil, Still looks good to me :) Nit: empty line 83 of the new test is not required! Jc On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov wrote: Hi Alex, Please review the updated webrev that has new test moved to test/jdk/comsun/jdi/connect folder. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil ?On 9/24/18, 2:56 PM, "Alex Menkov" wrote: Daniil, Just remembered that SQE requested to not add new tests to vmTestbase (see test/hotspot/jtreg/vmTestbase/README.md) Could you please move the test to correct location (I suppose it's test/jdk/com/sun/jdi) --alex On 09/24/2018 14:30, Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 10:39, Gary Adams wrote: >> Looks good to me. >> >> On 9/24/18, 1:25 PM, Daniil Titov wrote: >>> Hi Alex and Gary, >>> >>> Please review the updated patch that includes suggested changes. >>> >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >>> Thanks! >>> --Daniil >>> >>> >>> >>> >>> ?On 9/21/18, 3:59 PM, "Alex Menkov" wrote: >>> >>> One more note: >>> please add "@Override" annotation to the >>> SocketListeningConnector.updateArgumentMapIfRequired >>> >>> --alex >>> >>> On 09/21/2018 02:26, gary.adams at oracle.com wrote: >>> > Looks good to me. >>> > >>> > For the javadoc >>> > >>> > 72 *

>>> > 73 * Ifarguments contains addressing >>> information. and >>> > 74 * only one connection will be accepted, the {@link >>> #accept accept} method >>> > 75 * can be called immediately without calling this >>> method. >>> > 76 * >>> > 77 * If the addressing information provided >>> inarguments >>> > implies >>> > 78 * the auto detection this information might be updated >>> with the address >>> > 79 * of the started listener. >>> > >>> > - you could add a

tag if you want to maintain the >>> spacing in the >>> > generated javadoc. >>> > - I've seen other changesets migrating to {@code ..} from >>> the older >>> > ... >>> > >>> > It would be good to include some negative testing. >>> > Not sure if it is already covered in other tests, e.g. >>> > >>> > args1 = defaultArguments() >>> > startListening(args1) // bound port updated >>> > startListening(args1) // already listening >>> > >>> > >>> > On 9/20/18 10:59 PM, Daniil Titov wrote: >>> >> Please review the change that fixes the issue in >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. >>> >> >>> >> When the argument map passed to startListening() methods has >>> the port number unspecified or set to zero the port is auto detected. >>> However, the consequent call of startListening() methods with >>> unspecified port number fails rather than starts a new listener on >>> auto detected port. This happens since the original argument map >>> passed to the startListening() methods is used as a key to store the >>> mapping to the started listeners. >>> >> >>> >> The fix ensures that in cases when the port is auto detected >>> the argument map is updated with the bound port number. >>> >> >>> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. >>> >> >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> > >>> >>> >>> >> -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Sep 25 17:50:53 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 25 Sep 2018 10:50:53 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> Message-ID: Looks great to me, thanks! (Not a reviewer though :)) Jc On Tue, Sep 25, 2018 at 10:32 AM Daniil Titov wrote: > HI JC, > > > > The webrev is updated to address this. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > > *From: *JC Beyler > *Date: *Monday, September 24, 2018 at 8:47 PM > *To: * > *Cc: *, , < > serviceability-dev at openjdk.java.net> > *Subject: *Re: RFR 8163083: SocketListeningConnector does not allow > invocations with port 0 > > > > Hi Daniil, > > > > Still looks good to me :) > > > > Nit: empty line 83 of the new test is not required! > > Jc > > > > On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov > wrote: > > Hi Alex, > > Please review the updated webrev that has new test moved to > test/jdk/comsun/jdi/connect folder. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > ?On 9/24/18, 2:56 PM, "Alex Menkov" wrote: > > Daniil, > > Just remembered that SQE requested to not add new tests to vmTestbase > (see test/hotspot/jtreg/vmTestbase/README.md) > Could you please move the test to correct location (I suppose it's > test/jdk/com/sun/jdi) > > --alex > > > On 09/24/2018 14:30, Alex Menkov wrote: > > +1 > > > > --alex > > > > On 09/24/2018 10:39, Gary Adams wrote: > >> Looks good to me. > >> > >> On 9/24/18, 1:25 PM, Daniil Titov wrote: > >>> Hi Alex and Gary, > >>> > >>> Please review the updated patch that includes suggested changes. > >>> > >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > >>> > >>> Thanks! > >>> --Daniil > >>> > >>> > >>> > >>> > >>> ?On 9/21/18, 3:59 PM, "Alex Menkov" > wrote: > >>> > >>> One more note: > >>> please add "@Override" annotation to the > >>> SocketListeningConnector.updateArgumentMapIfRequired > >>> > >>> --alex > >>> > >>> On 09/21/2018 02:26, gary.adams at oracle.com wrote: > >>> > Looks good to me. > >>> > > >>> > For the javadoc > >>> > > >>> > 72 *

> >>> > 73 * Ifarguments contains addressing > >>> information. and > >>> > 74 * only one connection will be accepted, the > {@link > >>> #accept accept} method > >>> > 75 * can be called immediately without calling > this > >>> method. > >>> > 76 * > >>> > 77 * If the addressing information provided > >>> inarguments > >>> > implies > >>> > 78 * the auto detection this information might be updated > >>> with the address > >>> > 79 * of the started listener. > >>> > > >>> > - you could add a

tag if you want to maintain the > >>> spacing in the > >>> > generated javadoc. > >>> > - I've seen other changesets migrating to {@code ..} > from > >>> the older > >>> > ... > >>> > > >>> > It would be good to include some negative testing. > >>> > Not sure if it is already covered in other tests, e.g. > >>> > > >>> > args1 = defaultArguments() > >>> > startListening(args1) // bound port updated > >>> > startListening(args1) // already listening > >>> > > >>> > > >>> > On 9/20/18 10:59 PM, Daniil Titov wrote: > >>> >> Please review the change that fixes the issue in > >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. > >>> >> > >>> >> When the argument map passed to startListening() methods > has > >>> the port number unspecified or set to zero the port is auto > detected. > >>> However, the consequent call of startListening() methods with > >>> unspecified port number fails rather than starts a new listener on > >>> auto detected port. This happens since the original argument map > >>> passed to the startListening() methods is used as a key to store > the > >>> mapping to the started listeners. > >>> >> > >>> >> The fix ensures that in cases when the port is auto > detected > >>> the argument map is updated with the bound port number. > >>> >> > >>> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. > >>> >> > >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > >>> >> Webrev: > http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > >>> >> > >>> >> Thanks! > >>> >> --Daniil > >>> >> > >>> >> > >>> >> > >>> > > >>> > >>> > >>> > >> > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Tue Sep 25 17:53:19 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 25 Sep 2018 10:53:19 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> Message-ID: <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> +1 --alex On 09/24/2018 11:40, Igor Ignatyev wrote: > (cc-ing hotspot-dev alias) > > Hi Jc, > > the fix looks good to me. don't forget to clean up nsk/share/jni/README at the end. > > Thanks, > -- Igor > >> On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: >> >> Hi all, >> >> As the tests have become C++ tests, the NSK_CPP_STUBS are no longer needed. I did two awk scripts to remove them and will be rolling them out in 50 file max reviews to streamline the reviews for the reviewers. >> >> So here is the first which handles all the cases outside of the jvmti subfolder: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 >> >> The bug contains information on the two scripts I used. >> >> Thanks, >> Jc > From alexey.menkov at oracle.com Tue Sep 25 18:08:35 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 25 Sep 2018 11:08:35 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> Message-ID: <183f3875-60b3-ed1c-97bd-ad206dbf4be8@oracle.com> Looks good. --alex On 09/25/2018 10:32, Daniil Titov wrote: > HI JC, > > The webrev is updated to address this. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > *From: *JC Beyler > *Date: *Monday, September 24, 2018 at 8:47 PM > *To: * > *Cc: *, , > > *Subject: *Re: RFR 8163083: SocketListeningConnector does not allow > invocations with port 0 > > Hi Daniil, > > Still looks good to me :) > > Nit: empty line 83 of the new test is not required! > > Jc > > On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov > wrote: > > Hi Alex, > > Please review the updated webrev that has new test moved to > test/jdk/comsun/jdi/connect folder. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > ?On 9/24/18, 2:56 PM, "Alex Menkov" > wrote: > > ? ? Daniil, > > ? ? Just remembered that SQE requested to not add new tests to > vmTestbase > ? ? (see test/hotspot/jtreg/vmTestbase/README.md) > ? ? Could you please move the test to correct location (I suppose it's > ? ? test/jdk/com/sun/jdi) > > ? ? --alex > > > ? ? On 09/24/2018 14:30, Alex Menkov wrote: > ? ? > +1 > ? ? > > ? ? > --alex > ? ? > > ? ? > On 09/24/2018 10:39, Gary Adams wrote: > ? ? >> Looks good to me. > ? ? >> > ? ? >> On 9/24/18, 1:25 PM, Daniil Titov wrote: > ? ? >>> Hi Alex and Gary, > ? ? >>> > ? ? >>> Please review the updated patch that includes suggested > changes. > ? ? >>> > ? ? >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > > ? ? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>> > ? ? >>> Thanks! > ? ? >>> --Daniil > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> ?On 9/21/18, 3:59 PM, "Alex > Menkov"> > wrote: > ? ? >>> > ? ? >>>? ? ? One more note: > ? ? >>>? ? ? please add "@Override" annotation to the > ? ? >>>? ? ? SocketListeningConnector.updateArgumentMapIfRequired > ? ? >>> > ? ? >>>? ? ? --alex > ? ? >>> > ? ? >>>? ? ? On 09/21/2018 02:26, gary.adams at oracle.com > wrote: > ? ? >>>? ? ? >? Looks good to me. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? For the javadoc > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?72? ? ? *

> ? ? >>>? ? ? >? ? ?73? ? ? * Ifarguments? contains > addressing > ? ? >>> information. and > ? ? >>>? ? ? >? ? ?74? ? ? * only one connection will be accepted, > the {@link > ? ? >>> #accept accept} method > ? ? >>>? ? ? >? ? ?75? ? ? * can be called immediately without > calling this > ? ? >>> method. > ? ? >>>? ? ? >? ? ?76? ? ? * > ? ? >>>? ? ? >? 77 * If the addressing information provided > ? ? >>> inarguments > ? ? >>>? ? ? >? implies > ? ? >>>? ? ? >? 78 * the auto detection this information might be > updated > ? ? >>> with the address > ? ? >>>? ? ? >? 79 * of the started listener. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?- you could add a

? tag if you want to > maintain the > ? ? >>> spacing in the > ? ? >>>? ? ? >? generated javadoc. > ? ? >>>? ? ? >? ? ?- I've seen other changesets migrating to {@code > ..} from > ? ? >>> the older > ? ? >>>? ? ? >? ... > ? ? >>>? ? ? > > ? ? >>>? ? ? >? It would be good to include some negative testing. > ? ? >>>? ? ? >? Not sure if it is already covered in other tests, e.g. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ? ?args1 = defaultArguments() > ? ? >>>? ? ? >? ? ? ?startListening(args1)? ?// bound port updated > ? ? >>>? ? ? >? ? ? ?startListening(args1)? ?// already listening > ? ? >>>? ? ? > > ? ? >>>? ? ? > > ? ? >>>? ? ? >? On 9/20/18 10:59 PM, Daniil Titov wrote: > ? ? >>>? ? ? >>? Please review the change that fixes the issue in > ? ? >>> com.sun.tools.jdi.SocketListenerConnector.startListening() > method. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? When the argument map passed to startListening() > methods has > ? ? >>> the port number unspecified or set to zero the port is auto > detected. > ? ? >>> However,? the consequent call of startListening() methods with > ? ? >>> unspecified port number fails rather than starts a new > listener on > ? ? >>> auto detected port. This happens since the original > argument map > ? ? >>> passed to the startListening() methods is used as a key to > store the > ? ? >>> mapping to the started listeners. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? The fix ensures that in cases when the port is > auto detected > ? ? >>> the argument map is updated with the bound port number. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Mach5 vmTestbase_nsk_jdi tests successfully passed. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>>? ? ? >> > Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Thanks! > ? ? >>>? ? ? >>? --Daniil > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? > > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >> > > > > -- > > Thanks, > > Jc > From jini.george at oracle.com Wed Sep 26 04:11:48 2018 From: jini.george at oracle.com (Jini George) Date: Wed, 26 Sep 2018 09:41:48 +0530 Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> Message-ID: <8f78ff9f-a548-5d5f-bdb0-f366877d2226@oracle.com> Looks good to me. Thanks, Jini. On 9/24/2018 9:19 AM, Sharath Ballal wrote: > Hi, > > Pls review this test fix to add "-Xmx512m" to SA tests which create > either core file or heap dump, to avoid timeout due to large heap sizes. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > SA tests passed on Mach5 run. > > Thanks, > > Sharath > From sharath.ballal at oracle.com Wed Sep 26 04:26:55 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 25 Sep 2018 21:26:55 -0700 (PDT) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: <8f78ff9f-a548-5d5f-bdb0-f366877d2226@oracle.com> References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <8f78ff9f-a548-5d5f-bdb0-f366877d2226@oracle.com> Message-ID: Thanks for the review Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Wednesday, September 26, 2018 9:42 AM To: Sharath Ballal; serviceability-dev Subject: Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Looks good to me. Thanks, Jini. On 9/24/2018 9:19 AM, Sharath Ballal wrote: > Hi, > > Pls review this test fix to add "-Xmx512m" to SA tests which create > either core file or heap dump, to avoid timeout due to large heap sizes. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > SA tests passed on Mach5 run. > > Thanks, > > Sharath > From fairoz.matte at oracle.com Wed Sep 26 08:07:22 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Wed, 26 Sep 2018 01:07:22 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> References: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> Message-ID: Hi Jini, Thanks for pointing out that, yes we cannot make that cleanup for JDK8. Keeping it very simple and taking only changes required to fix JDK-8164383 http://cr.openjdk.java.net/~fmatte/8164383/webrev.02/ I have verified running "test/serviceability/sa/jmap-hashcode/Test8028623.java" test case (found from one of the duplicate issue of JDK-8164383). Results are as expected before and after the patch on Solaris 12 and Solaris 10. Along with that, I have verified with Internal testing and found no issues Thanks, Fairoz > -----Original Message----- > From: Jini George > Sent: Tuesday, September 25, 2018 3:48 PM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core > > Hi Fairoz, > > I took a better look at the changes and I realized that the cleanup related to > SOLARIS_11_B159_OR_LATER would be valid for only JDK9 and later. Since > JDK8 is supported for Solaris 10 too, I believe that the cleanup related > changes done as a part of JDK-8164383 should not be done for JDK-8. > > Thanks! > Jini. > > On 9/24/2018 7:21 PM, Fairoz Matte wrote: > > Hi Jini, > > > >> -----Original Message----- > >> From: Jini George > >> Sent: Friday, September 21, 2018 4:07 PM > >> To: Fairoz Matte ; serviceability- > >> dev at openjdk.java.net > >> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on > >> Solaris 12 when loading dumped core > >> > >> Hi Fairoz, > >> > >> This looks good to me. One nit which got missed out in the original > >> change also is that in saproc.cpp, the following comments > >> > >> 452 > >> 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 > >> > >> 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later > >> 477 /*ARGSUSED*/ > >> > > > > I have incorporated above changes > > > >> would not be required anymore. And we would not need the wrapper to > >> the callback routine fill_cframe_list() -- as in, we would need only > >> one routine with the appropriate arguments passed. But you are free > >> to ignore this since this was not done as a part of the original change. > > > > Removed wrapper_fill_cframe_list function and fill_cframe_list function > has been used directly. > > > > Please find the updated webrev > > http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ > > > > Thanks, > > Fairoz > > > >> > >> Thanks, > >> Jini (Not a Reviewer). > >> > >> > >> > >> On 9/20/2018 7:06 PM, Fairoz Matte wrote: > >>> Hi, > >>> > >>> Kindly review the backport of "JDK-8164383 : jhsdb dumps core on > >>> Solaris 12 when loading dumped core" to 8u > >>> > >>> Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ > >>> > >>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 > >>> > >>> JDK9 changeset - > >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 > >>> > >>> JDK9 review thread - > >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-Octob > >>> er > >>> /020543.html > >>> > >>> Thanks, > >>> Fairoz > >>> From christoph.langer at sap.com Wed Sep 26 09:48:14 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Sep 2018 09:48:14 +0000 Subject: [CAUTION] RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef In-Reply-To: References: Message-ID: <3667f01e602a47a59739dfb6b73dcd5c@sap.com> Hi Matthias, looks good (and trivial). Ccing serviceability-dev because of change in libjdwp. Best regards Christoph From: nio-dev On Behalf Of Baesken, Matthias Sent: Mittwoch, 26. September 2018 11:25 To: 'build-dev at openjdk.java.net' ; net-dev ; nio-dev at openjdk.java.net Cc: Lindenmaier, Goetz ; Schmidt, Lutz Subject: [CAUTION] RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef Hello, please review this small build fix . After the recent changes to the gcc compile flags with 8211029 , most of our Linux builds stopped working . Error : === Output from failing command(s) repeated here === * For target support_native_java.base_libnet_DatagramPacket.o: In file included from /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/net_util.h:31:0, from /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/DatagramPacket.c:27: /OpenJDK/8210319/jdk/src/java.base/unix/native/libnet/net_util_md.h:50:7: error: "__solaris__" is not defined [-Werror=undef] #elif __solaris__ ^ After looking into it, it seems that the jdk/src/java.base/unix/native/libnet/net_util_md.h compile error is only triggered on older Linux OS (e.g. SLES11). Probably that's why it was not seen at Oracle after puhsing after 8211029 . Some greps showed me a number of similar problematic #elif-checks for OS, I adjusted them too . Bug / webrev : https://bugs.openjdk.java.net/browse/JDK-8211146 http://cr.openjdk.java.net/~mbaesken/webrevs/8211146.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Sep 26 11:41:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Sep 2018 07:41:23 -0400 Subject: [CAUTION] RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef In-Reply-To: <3667f01e602a47a59739dfb6b73dcd5c@sap.com> References: <3667f01e602a47a59739dfb6b73dcd5c@sap.com> Message-ID: <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com> That all seems fine to me. Thanks for fixing. David On 26/09/2018 5:48 AM, Langer, Christoph wrote: > Hi Matthias, > > looks good (and trivial). Ccing serviceability-dev because of change in > libjdwp. > > Best regards > > Christoph > > *From:*nio-dev *On Behalf Of > *Baesken, Matthias > *Sent:* Mittwoch, 26. September 2018 11:25 > *To:* 'build-dev at openjdk.java.net' ; net-dev > ; nio-dev at openjdk.java.net > *Cc:* Lindenmaier, Goetz ; Schmidt, Lutz > > *Subject:* [CAUTION] RFR : 8211146 : fix problematic elif-tests after > recent gcc warning changes Werror=undef > > Hello, please review this small build fix . > > After the recent? changes? to ?the gcc compile flags?? with? 8211029 > ?,? most of our? Linux builds stopped working . > > Error : > > === Output from failing command(s) repeated here === > > * For target support_native_java.base_libnet_DatagramPacket.o: > > In file included from > /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/net_util.h:31:0, > > ????????????????from > /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/DatagramPacket.c:27: > > /OpenJDK/8210319/jdk/src/java.base/unix/native/libnet/net_util_md.h:50:7: error: > "__solaris__" is not defined [-Werror=undef] > > #elif __solaris__ > > ?????? ^ > > After looking into it,? it seems? that? the > jdk/src/java.base/unix/native/libnet/net_util_md.h??? compile error is > only triggered on older Linux OS? (e.g. SLES11). > > Probably that?s why it was not seen at Oracle ?after? puhsing? after > 8211029?? . > > Some greps? showed me a number of similar problematic? #elif-checks for > OS, I adjusted them too . > > Bug / webrev : > > https://bugs.openjdk.java.net/browse/JDK-8211146 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211146.0/ > > > Thanks, Matthias > From gary.adams at oracle.com Wed Sep 26 14:55:10 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 26 Sep 2018 10:55:10 -0400 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" Message-ID: <5BAB9DCE.9040505@oracle.com> A race condition exists in hs203t003 between the main test thread and the processing in callbackFieldAccess processing. The main thread already includes a polling loop to wait for the redefine class operation to be performed, but it does not wait for the following suspend thread operation to be completed. This changeset adds an additional wait for the suspend thread to complete. It also checks the error returns from popThreadFrame and resumeThread to issue an additional error message if these native routines returned an error. Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8210984 From jcbeyler at google.com Wed Sep 26 16:42:13 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 26 Sep 2018 09:42:13 -0700 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: <5BAB9DCE.9040505@oracle.com> References: <5BAB9DCE.9040505@oracle.com> Message-ID: Hi Gary, Should you not also fail the test if the test fails at popping or resuming the thread? Apart from that looks good to me (I would remark normally that I'm getting rid of the NSK_CPP_STUBs so you could just jump the gun and remove it directly but this is consistent with the current code base and my scripts will get to it eventually...). Thanks, Jc On Wed, Sep 26, 2018 at 7:54 AM Gary Adams wrote: > A race condition exists in hs203t003 between the main test thread and > the processing in callbackFieldAccess processing. The main thread > already includes a polling loop to wait for the redefine class operation > to be performed, but it does not wait for the following suspend thread > operation to be completed. > > This changeset adds an additional wait for the suspend thread to complete. > It also checks the error returns from popThreadFrame and resumeThread > to issue an additional error message if these native routines returned > an error. > > Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8210984 > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Sep 26 17:03:14 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 26 Sep 2018 13:03:14 -0400 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: References: <5BAB9DCE.9040505@oracle.com> Message-ID: <5BABBBD2.9050806@oracle.com> The native code for popThreadFrame and resumeThread already set the failed agent status. These incremental steps are non fatal as far as the test is concerned. I even saw some test logs where the popThreadFrame failed, but the resumeThread succeeded, because the thread was suspended by that time. Best to save the code cleanup to a changeset specifically targetted at the cosmetic changes. On 9/26/18, 12:42 PM, JC Beyler wrote: > Hi Gary, > > Should you not also fail the test if the test fails at popping or > resuming the thread? > > Apart from that looks good to me (I would remark normally that I'm > getting rid of the NSK_CPP_STUBs so you could just jump the gun and > remove it directly but this is consistent with the current code base > and my scripts will get to it eventually...). > > Thanks, > Jc > > On Wed, Sep 26, 2018 at 7:54 AM Gary Adams > wrote: > > A race condition exists in hs203t003 between the main test thread and > the processing in callbackFieldAccess processing. The main thread > already includes a polling loop to wait for the redefine class > operation > to be performed, but it does not wait for the following suspend thread > operation to be completed. > > This changeset adds an additional wait for the suspend thread to > complete. > It also checks the error returns from popThreadFrame and resumeThread > to issue an additional error message if these native routines > returned > an error. > > Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8210984 > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 26 17:28:05 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 26 Sep 2018 10:28:05 -0700 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: <5BABBBD2.9050806@oracle.com> References: <5BAB9DCE.9040505@oracle.com> <5BABBBD2.9050806@oracle.com> Message-ID: Thanks for the explanation Gary, that makes sense and I agree with leaving the NSK_CPP_STUB code as is. It looks good to me, Jc On Wed, Sep 26, 2018 at 10:01 AM Gary Adams wrote: > The native code for popThreadFrame and resumeThread > already set the failed agent status. These incremental steps > are non fatal as far as the test is concerned. I even saw some > test logs where the popThreadFrame failed, but the > resumeThread succeeded, because the thread was suspended > by that time. > > Best to save the code cleanup to a changeset specifically targetted > at the cosmetic changes. > > > On 9/26/18, 12:42 PM, JC Beyler wrote: > > Hi Gary, > > Should you not also fail the test if the test fails at popping or resuming > the thread? > > Apart from that looks good to me (I would remark normally that I'm getting > rid of the NSK_CPP_STUBs so you could just jump the gun and remove it > directly but this is consistent with the current code base and my scripts > will get to it eventually...). > > Thanks, > Jc > > On Wed, Sep 26, 2018 at 7:54 AM Gary Adams wrote: > >> A race condition exists in hs203t003 between the main test thread and >> the processing in callbackFieldAccess processing. The main thread >> already includes a polling loop to wait for the redefine class operation >> to be performed, but it does not wait for the following suspend thread >> operation to be completed. >> >> This changeset adds an additional wait for the suspend thread to complete. >> It also checks the error returns from popThreadFrame and resumeThread >> to issue an additional error message if these native routines returned >> an error. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8210984 >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 26 17:40:21 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 26 Sep 2018 10:40:21 -0700 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: <5BAB9DCE.9040505@oracle.com> References: <5BAB9DCE.9040505@oracle.com> Message-ID: <404373b8-6315-8f0c-80ed-ea05c43fea30@oracle.com> Hi Gary, Should the following comment come first, not after the join() call: ?115???????????? mt.join(); ?116???????????? // Wait till the other thread completes its execution. Rather than using JVMTI to detect if the field is suspended, couldn't you have just set a static variable in callbackFieldAccess() and check it from isSuspended()? Before doing the fix, did you first check if the bug is easily reproduced by making is sleep for 1ms instead of 100ms? thanks, Chris On 9/26/18 7:55 AM, Gary Adams wrote: > A race condition exists in hs203t003 between the main test thread and > the processing in callbackFieldAccess processing. The main thread > already includes a polling loop to wait for the redefine class operation > to be performed, but it does not wait for the following suspend thread > operation to be completed. > > This changeset adds an additional wait for the suspend thread to > complete. > It also checks the error returns from popThreadFrame and resumeThread > to issue an additional error message if these native routines returned > an error. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ > ? Issue:? https://bugs.openjdk.java.net/browse/JDK-8210984 From gary.adams at oracle.com Wed Sep 26 18:07:08 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 26 Sep 2018 14:07:08 -0400 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: <404373b8-6315-8f0c-80ed-ea05c43fea30@oracle.com> References: <5BAB9DCE.9040505@oracle.com> <404373b8-6315-8f0c-80ed-ea05c43fea30@oracle.com> Message-ID: <5BABCACC.6080204@oracle.com> On 9/26/18, 1:40 PM, Chris Plummer wrote: > Hi Gary, > > Should the following comment come first, not after the join() call: > > 115 mt.join(); > 116 // Wait till the other thread completes its execution. I'll move the comment up. > > Rather than using JVMTI to detect if the field is suspended, couldn't > you have just set a static variable in callbackFieldAccess() and check > it from isSuspended()? All of the other native calls take a thread and operate on it. It seemed reasonable to use the same check that popThreadFrame used. > > Before doing the fix, did you first check if the bug is easily > reproduced by making is sleep for 1ms instead of 100ms? That's how I got the problem to reproduce. Switching to sleep(1) got 5 failures in 300 testruns. > > thanks, > > Chris > > On 9/26/18 7:55 AM, Gary Adams wrote: >> A race condition exists in hs203t003 between the main test thread and >> the processing in callbackFieldAccess processing. The main thread >> already includes a polling loop to wait for the redefine class operation >> to be performed, but it does not wait for the following suspend thread >> operation to be completed. >> >> This changeset adds an additional wait for the suspend thread to >> complete. >> It also checks the error returns from popThreadFrame and resumeThread >> to issue an additional error message if these native routines >> returned an error. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8210984 > > > From chris.plummer at oracle.com Wed Sep 26 18:12:24 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 26 Sep 2018 11:12:24 -0700 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: <5BABCACC.6080204@oracle.com> References: <5BAB9DCE.9040505@oracle.com> <404373b8-6315-8f0c-80ed-ea05c43fea30@oracle.com> <5BABCACC.6080204@oracle.com> Message-ID: <14e03139-177f-e04d-2640-ad88ff6d413f@oracle.com> On 9/26/18 11:07 AM, Gary Adams wrote: > On 9/26/18, 1:40 PM, Chris Plummer wrote: >> Hi Gary, >> >> Should the following comment come first, not after the join() call: >> >> ?115???????????? mt.join(); >> ?116???????????? // Wait till the other thread completes its execution. > I'll move the comment up. >> >> Rather than using JVMTI to detect if the field is suspended, couldn't >> you have just set a static variable in callbackFieldAccess() and >> check it from isSuspended()? > All of the other native calls take a thread and operate on it. > It seemed reasonable to use the same check that popThreadFrame used. > >> >> Before doing the fix, did you first check if the bug is easily >> reproduced by making is sleep for 1ms instead of 100ms? > That's how I got the problem to reproduce. > Switching to sleep(1) got 5 failures in 300 testruns. Ok, and I assume you then tested the fix with the 1ms sleep? If so, then ship it. Otherwise do this testing first. thanks, Chris >> >> thanks, >> >> Chris >> >> On 9/26/18 7:55 AM, Gary Adams wrote: >>> A race condition exists in hs203t003 between the main test thread and >>> the processing in callbackFieldAccess processing. The main thread >>> already includes a polling loop to wait for the redefine class >>> operation >>> to be performed, but it does not wait for the following suspend thread >>> operation to be completed. >>> >>> This changeset adds an additional wait for the suspend thread to >>> complete. >>> It also checks the error returns from popThreadFrame and resumeThread >>> to issue an additional error message if these native routines >>> returned an error. >>> >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ >>> ? Issue:? https://bugs.openjdk.java.net/browse/JDK-8210984 >> >> >> > From serguei.spitsyn at oracle.com Thu Sep 27 03:12:39 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 26 Sep 2018 20:12:39 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> Message-ID: Hi Daniil, It is great that you came up the fix for this issue. Thanks to Gary for the help too. I wonder if we could get away without updating the javadoc of com/sun/jdi/connect/ListeningConnector.java. Filing a CSR would not be needed then (simple javadoc reformatting should not require a CSR). So, my question is if this new fragment is really needed: 76 *

77 * If the addressing information provided in {@code arguments} implies 78 * the auto detection this information might be updated with the address 79 * of the started listener. The javadoc for startListening already has this fragment: 61 * The argument map associates argument name strings to instances 62 * of {@link Connector.Argument}. The default argument map for a 63 * connector can be obtained through {@link Connector#defaultArguments}. 64 * Argument map values can be changed, but map entries should not be 65 * added or deleted. that allows to change the argument map values. It looks like, it has to be Okay to add the bound port number there. Please, let me know what you think. Some formatting comments to addition to Jc's comments: 77 * If the addressing information provided in {@code arguments} implies 78 * the auto detection this information might be updated with the address 79 * of the started listener. ? This sentence needs to be split in two: 77 * If the addressing information provided in {@code arguments} implies 78 * the auto detection. This information might be updated with the address 79 * of the started listener. + + protected void updateArgumentMapIfRequired( + Map args,TransportService.ListenKey listener) { + } + The indent has to be 4, not 8. + if(isWildcardPort(args)) { + String[] address = listener.address().split(":"); + if (address.length > 1) { + args.get(ARG_PORT).setValue(address[1]); + } + } A space is missed after the first 'if'. 50 filter(c -> 51 c.name().equals("com.sun.jdi.SocketListen")).findFirst().get(); ? This is better to be one liner. 57 testWithDefaultArgs(connector); 58 testWithDefaultArgs2(connector); 59 testWithWildcardPort(connector); 60 testWithWildcardPort2(connector); A suggestion is to rename above as below to have the names more unified: 57 testWithDefaultArgs1(connector); 58 testWithDefaultArgs2(connector); 59 testWithWildcardPort1(connector); 60 testWithWildcardPort2(connector); Thanks, Serguei On 9/25/18 10:32 AM, Daniil Titov wrote: > > HI JC, > > The webrev is updated to address this. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > *From: *JC Beyler > *Date: *Monday, September 24, 2018 at 8:47 PM > *To: * > *Cc: *, , > > *Subject: *Re: RFR 8163083: SocketListeningConnector does not allow > invocations with port 0 > > Hi Daniil, > > Still looks good to me :) > > Nit: empty line 83 of the new test is not required! > > Jc > > On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov > > wrote: > > Hi Alex, > > Please review the updated webrev that has new test moved to > test/jdk/comsun/jdi/connect folder. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > ?On 9/24/18, 2:56 PM, "Alex Menkov" > wrote: > > ? ? Daniil, > > ? ? Just remembered that SQE requested to not add new tests to > vmTestbase > ? ? (see test/hotspot/jtreg/vmTestbase/README.md) > ? ? Could you please move the test to correct location (I suppose > it's > ? ? test/jdk/com/sun/jdi) > > ? ? --alex > > > ? ? On 09/24/2018 14:30, Alex Menkov wrote: > ? ? > +1 > ? ? > > ? ? > --alex > ? ? > > ? ? > On 09/24/2018 10:39, Gary Adams wrote: > ? ? >> Looks good to me. > ? ? >> > ? ? >> On 9/24/18, 1:25 PM, Daniil Titov wrote: > ? ? >>> Hi Alex and Gary, > ? ? >>> > ? ? >>> Please review the updated patch that includes suggested > changes. > ? ? >>> > ? ? >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > > ? ? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>> > ? ? >>> Thanks! > ? ? >>> --Daniil > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> ?On 9/21/18, 3:59 PM, "Alex > Menkov" > wrote: > ? ? >>> > ? ? >>>? ? ? One more note: > ? ? >>>? ? ? please add "@Override" annotation to the > ? ? >>> SocketListeningConnector.updateArgumentMapIfRequired > ? ? >>> > ? ? >>>? ? ? --alex > ? ? >>> > ? ? >>>? ? ? On 09/21/2018 02:26, gary.adams at oracle.com > wrote: > ? ? >>>? ? ? >? Looks good to me. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? For the javadoc > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?72? ? ? *

> ? ? >>>? ? ? >? ? ?73? ? ? * Ifarguments? contains > addressing > ? ? >>> information. and > ? ? >>>? ? ? >? ? ?74? ? ? * only one connection will be accepted, > the {@link > ? ? >>> #accept accept} method > ? ? >>>? ? ? >? ? ?75? ? ? * can be called immediately without > calling this > ? ? >>> method. > ? ? >>>? ? ? >? ? ?76? ? ? * > ? ? >>>? ? ? >? 77 * If the addressing information provided > ? ? >>> inarguments > ? ? >>>? ? ? >? implies > ? ? >>>? ? ? >? 78 * the auto detection this information might be > updated > ? ? >>> with the address > ? ? >>>? ? ? >? 79 * of the started listener. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?- you could add a

tag if you want to > maintain the > ? ? >>> spacing in the > ? ? >>>? ? ? >? generated javadoc. > ? ? >>>? ? ? >? ? ?- I've seen other changesets migrating to > {@code ..} from > ? ? >>> the older > ? ? >>>? ? ? >? ... > ? ? >>>? ? ? > > ? ? >>>? ? ? >? It would be good to include some negative testing. > ? ? >>>? ? ? >? Not sure if it is already covered in other tests, e.g. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ? ?args1 = defaultArguments() > ? ? >>>? ? ? >? ? ? ?startListening(args1) ?// bound port updated > ? ? >>>? ? ? >? ? ? ?startListening(args1) ?// already listening > ? ? >>>? ? ? > > ? ? >>>? ? ? > > ? ? >>>? ? ? >? On 9/20/18 10:59 PM, Daniil Titov wrote: > ? ? >>>? ? ? >>? Please review the change that fixes the issue in > ? ? >>> com.sun.tools.jdi.SocketListenerConnector.startListening() > method. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? When the argument map passed to startListening() > methods has > ? ? >>> the port number unspecified or set to zero the port is > auto detected. > ? ? >>> However,? the consequent call of startListening() methods > with > ? ? >>> unspecified port number fails rather than starts a new > listener on > ? ? >>> auto detected port. This happens since the original > argument map > ? ? >>> passed to the startListening() methods is used as a key to > store the > ? ? >>> mapping to the started listeners. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? The fix ensures that in cases when the port is > auto detected > ? ? >>> the argument map is updated with the bound port number. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Mach5 vmTestbase_nsk_jdi tests successfully passed. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>>? ? ? >>? > Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Thanks! > ? ? >>>? ? ? >>? --Daniil > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? > > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >> > > > > -- > > Thanks, > > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 27 03:37:51 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 26 Sep 2018 20:37:51 -0700 Subject: RFR (M) 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* Message-ID: Hi all, I continued the NSK_CPP_STUB removal with this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 This does the first 50 files of the jvmti subfolder, it is done automatically by the scripts I put in the bug comments. Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 27 03:51:26 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 26 Sep 2018 20:51:26 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> Message-ID: Hi all, Anybody on the hotspot-dev list have any comments or a LGTM? Thanks! Jc On Tue, Sep 25, 2018 at 10:56 AM Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 11:40, Igor Ignatyev wrote: > > (cc-ing hotspot-dev alias) > > > > Hi Jc, > > > > the fix looks good to me. don't forget to clean up nsk/share/jni/README > at the end. > > > > Thanks, > > -- Igor > > > >> On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: > >> > >> Hi all, > >> > >> As the tests have become C++ tests, the NSK_CPP_STUBS are no longer > needed. I did two awk scripts to remove them and will be rolling them out > in 50 file max reviews to streamline the reviews for the reviewers. > >> > >> So here is the first which handles all the cases outside of the jvmti > subfolder: > >> > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ < > http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 < > https://bugs.openjdk.java.net/browse/JDK-8211036> > >> > >> The bug contains information on the two scripts I used. > >> > >> Thanks, > >> Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 27 03:52:13 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 26 Sep 2018 20:52:13 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> Message-ID: Ping on this, anybody have time to do a review and give a LGTM? Or David if you have time and will to provide an explicit LGTM :) Thanks, Jc On Mon, Sep 24, 2018 at 9:18 AM JC Beyler wrote: > Hi David, > > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting for an > explicit LGTM from you or from someone else on this list to do a review. > > Thanks again for your help, > Jc > > On Sun, Sep 23, 2018 at 9:22 AM David Holmes > wrote: > >> Hi Jc, >> >> I don't think it is an issue for this to go ahead. If the static >> analysis tool has an issue then we can either find out how to teach it >> about this code structure, or else flag the issues as false positives. >> I'd be relying on one of the serviceability team here to handle that if >> the problem arises. >> >> Thanks, >> David >> >> On 23/09/2018 12:17 PM, JC Beyler wrote: >> > Hi David, >> > >> > No worries with the time to answer; I appreciate the review! >> > >> > That's a fair point. Is it possible to "describe" to the static >> analysis >> > tool to "trust" calls made in the SafeJNIEnv class? >> > >> > Otherwise, do you have any idea on how to go forward? For what it's >> > worth, this current webrev does not try to replace exception checking >> > with the SafeJNIEnv (it actually adds it), so for now the >> > question/solution could be delayed. I could continue working on this in >> > the scope of both the nsk/gc/lock/jniref code base and the NSK_VERIFIER >> > macro removal and we can look at how to tackle the cases where the >> tests >> > are actually calling exception checking (I know my heapmonitor does for >> > example). >> > >> > Let me know what you think and thanks for the review, >> > Jc >> > >> > >> > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > > > wrote: >> > >> > Hi Jc, >> > >> > Sorry for the delay on getting back to this but I'm travelling at >> the >> > moment. >> > >> > This looks quite neat. Thanks also to Alex for all the suggestions. >> > >> > My only remaining concern is that static analysis tools may not like >> > this because they may not be able to determine that we won't make >> > subsequent JNI calls when an exception happens in the first. That's >> not >> > a reason not to do this of course, just flagging that we may have >> to do >> > something to deal with that problem. >> > >> > Thanks, >> > David >> > >> > On 20/09/2018 11:56 AM, JC Beyler wrote: >> > > Hi Alex, >> > > >> > > Done here, thanks for the review: >> > > >> > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >> > >> > > >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > >> > > Thanks again! >> > > Jc >> > > >> > > >> > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov >> > >> > > > > >> wrote: >> > > >> > > Hi Jc, >> > > >> > > Looks good to me. >> > > A minor note: >> > > - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid >> > global >> > > namespece pollution (ErrorHandler is too generic name). >> > > >> > > --alex >> > > >> > > On 09/19/2018 15:56, JC Beyler wrote: >> > > > Hi Alex, >> > > > >> > > > I've updated the webrev to: >> > > > Webrev: >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >> > >> > > >> > > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> >> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > >> > > > That webrev has the code that is shown here in snippets. >> > > > >> > > > >> > > > Thanks for the reviews, I've relatively followed your >> reviews >> > > except for >> > > > one detail due to me wanting to handle the NSK_JNI_VERIFY >> > macros via >> > > > this system as well later down the road. For an example: >> > > > >> > > > We currently have in the code: >> > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >> > NSK_CPP_STUB2(GetObjectClass, >> > > > pEnv, mhToCall)) != NULL) ) >> > > > >> > > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor >> > > (JDK-8210728) >> > > > to: >> > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >> > pEnv->GetObjectClass(pEnv, >> > > > mhToCall)) != NULL) ) >> > > > >> > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and >> it >> > > becomes via >> > > > this wrapping of JNIEnv: >> > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) >> > > > >> > > > 3) Then, via removing the assignment, we'd arrive to a: >> > > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); >> > > > if (!mhClass) >> > > > >> > > > Without any loss of checking for failures, etc. >> > > > >> > > > So that is my motivation for most of this work with a >> concrete >> > > example >> > > > (hopefully it helps drive this conversation). >> > > > >> > > > I inlined my answers here, let me know what you think. >> > > > >> > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov >> > > >> > > >> > > > > > >> > > > > >>> wrote: >> > > > >> > > > Hi Jc, >> > > > >> > > > Updated tests looks good. >> > > > Some notes about implementation. >> > > > >> > > > - FatalOnException implements both verification and >> error >> > > handling >> > > > It would be better to separate them (and this makes >> > easy to >> > > implement >> > > > error handling different from JNIEnv::FatalError). >> > > > The simplest way is to define error handler as >> > > > class SafeJNIEnv { >> > > > public: >> > > > typedef void (*ErrorHandler)(JNIEnv *env, const >> > char* >> > > errorMsg); >> > > > // error handler which terminates jvm by using >> > FatalError() >> > > > static void FatalError(JNIEnv *env, const char >> > *errrorMsg); >> > > > >> > > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler >> > errorHandler = >> > > > FatalError); >> > > > (SafeJNIEnv methods should create FatalOnException >> objects >> > > passing >> > > > errorHandler) >> > > > >> > > > >> > > > >> > > > Agreed, I tried to keep the code simple. The concepts you >> > talk about >> > > > here are generally what I reserve for when I need it (ie >> > > extensions and >> > > > handling new cases). But a lot are going to be needed soon >> > so I >> > > think it >> > > > is a good time to iron the code out now on this "simple" >> > webrev. >> > > > >> > > > So done for this. >> > > > >> > > > >> > > > >> > > > - FatalOnException is used in SafeJNIEnv methods as >> > > > FatalOnException marker(this, "msg"); >> > > > ret = >> > > > (optional)marker.check_for_null(ret); >> > > > return ret; >> > > > But actually I'd call it something like >> > JNICallResultVerifier and >> > > > create >> > > > the object after JNI call. like >> > > > ret = >> > > > JNICallResultVerifier(this, "msg") >> > > > (optional).notNull(ret); >> > > > return ret; >> > > > or even (if you like such syntax sugar) you can define >> > > > template >> > > > T resultNotNull(T result) { >> > > > notNull(result); >> > > > return result; >> > > > } >> > > > and do >> > > > ret = >> > > > return JNICallResultVerifier(this, >> > "msg").resultNotNull(ret); >> > > > >> > > > >> > > > So I renamed FatalOnException to now being JNIVerifier. >> > > > >> > > > Though I like it, I don't think we can do it, except if we >> > do it >> > > > slightly differently: >> > > > I'm trying to solve two problems with one stone: >> > > > - How to check for returns of JNI calls in the way >> that is >> > > done here >> > > > - How to remove NSK_JNI_VERIFY* (from >> > nsk/share/jni/jni_tools) >> > > > >> > > > However, the NSK_JNI_VERIFY need to start a tracing system >> > before >> > > the >> > > > call to JNI, so it won't work this way. (Side question >> > would be >> > > do we >> > > > still care about the tracing in NSK_JNI_VERIFY, if we >> > don't then >> > > your >> > > > solution works well in most situations). >> > > > >> > > > My vision or intuition is that we would throw a template >> > at some >> > > point >> > > > on SafeJNIEnv to handle both cases and have JNIVerifier >> > become a >> > > > specialization in certain cases and something different >> > for the >> > > > NSK_JNI_VERIFY case (or have a different constructor to >> enable >> > > tracing). >> > > > But for now, I offer the implementation that does: >> > > > >> > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { >> > > > JNIVerifier marker(this, "GetObjectClass"); >> > > > return >> marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >> > > > } >> > > > >> > > > and: >> > > > >> > > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID >> > field, jobject >> > > > value) { >> > > > JNIVerifier<> marker(this, "SetObjectField"); >> > > > _jni_env->SetObjectField(obj, field, value); >> > > > } >> > > > >> > > > >> > > > >> > > > >> > > > - you added #include in the test (and you >> have to >> > > add it to >> > > > every test). >> > > > It would be simpler to add the include to >> > SafeJNIEnv.hpp and >> > > define >> > > > typedef std::unique_ptr SafeJNIEnvPtr; >> > > > Then each in the test methods: >> > > > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); >> > > > or you can add >> > > > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, >> > > ErrorHandler >> > > > errorHandler = fatalError) >> > > > and get >> > > > SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); >> > > > >> > > > >> > > > Done, I like that, even less code change to tests then. >> > > > >> > > > >> > > > >> > > > - it would be better to wrap internal classes >> > > (FatalOnException) into >> > > > unnamed namespace - this helps to avoid conflicts with >> > other >> > > classes) >> > > > >> > > > - FatalOnException::check_for_null(void* ptr) >> > > > should be >> > > > FatalOnException::check_for_null(const void* ptr) >> > > > And calling the method you don't need reinterpret_cast >> > > > >> > > > >> > > > Also done, it got renamed to ResultNotNull, is using a >> > template >> > > now, but >> > > > agreed, that worked. >> > > > Thanks again for the review, >> > > > Jc >> > > > >> > > > >> > > > --alex >> > > > >> > > > >> > > > On 09/18/2018 11:07, JC Beyler wrote: >> > > > > Hi David, >> > > > > >> > > > > Thanks for the quick review and thoughts. I have >> > now a new >> > > > version here >> > > > > that addresses your comments: >> > > > > >> > > > > Webrev: >> > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >> > >> > > >> > > > >> > >> > > > > >> > >> > > > > Bug: >> https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > > >> > > > > I've also inlined my answers/comments. >> > > > > >> > > > > >> > > > > >> > > > > > I've slowly started working on JDK-8191519 >> > > > > > >> > . >> > > > However before >> > > > > > starting to really refactor all the tests, I >> > > thought I'd >> > > > get a few >> > > > > > opinions. I am working on internalizing the >> > error >> > > handling >> > > > of JNI >> > > > > calls >> > > > > > via a SafeJNIEnv class that redefines all >> > the JNI >> > > calls to >> > > > add an >> > > > > error >> > > > > > checker. >> > > > > > >> > > > > > The advantage is that the test code will >> > look and >> > > feel like >> > > > > normal JNI >> > > > > > code and calls but will have the checks we >> > want to have >> > > > for our >> > > > > tests. >> > > > > >> > > > > Not sure I get that. Normal JNI code has to >> > check for >> > > > errors/exceptions >> > > > > after every call. The tests need those checks >> too. >> > > Today they are >> > > > > explicit, with this change they become >> > implicit. Not sure >> > > > what we are >> > > > > gaining here ?? >> > > > > >> > > > > >> > > > > In my humble opinion, having the error checking out >> > of the way >> > > > allows >> > > > > the code reader to concentrate on the JNI code >> while >> > > maintaining >> > > > error >> > > > > checking. We use something similar internally, so >> > perhaps I'm >> > > > biased to >> > > > > it :-). >> > > > > If this is not a desired/helpful "feature" to >> simplify >> > > tests in >> > > > general, >> > > > > I will backtrack it and just add the explicit tests >> > to the >> > > native >> > > > code >> > > > > of the locks for the fix >> > > > > >> > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. >> > > > > >> > > > > Let me however try to make my case and let me know >> what >> > > you all >> > > > think! >> > > > > >> > > > > >> > > > > > If agreed with this, we can augment the >> > SafeJNIEnv >> > > class >> > > > as needed. >> > > > > > Also, if the tests require something else >> > than fatal >> > > > errors, we >> > > > > can add >> > > > > > a different marker and make it a parameter >> > to the >> > > base class. >> > > > > > >> > > > > > Webrev: >> > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >> > >> > > >> > > > >> > >> > > > > >> > > > > >> > > > > > >> > > >> > > > > > Bug: >> > https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > > > >> > > > > > Let me know what you think, >> > > > > >> > > > > Two initial suggestions: >> > > > > >> > > > > 1. FatalOnException should be constructed with >> a >> > > description >> > > > string so >> > > > > that it can report the failing operation when >> > calling >> > > > FatalError rather >> > > > > than the general "Problem with a JNI call". >> > > > > >> > > > > >> > > > > Agreed with you, the new webrev produces: >> > > > > >> > > > > FATAL ERROR in native method: GetObjectClass >> > > > > at >> > > > >> > > >> > >> nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >> > > > > at >> > > > >> > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >> > > > Method) >> > > > > at >> > > > >> > > >> > >> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >> > > > > at >> > > > >> > > >> > >> nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >> > > > > at >> > > > >> > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) >> > > > > >> > > > > >> > > > > and for a return NULL in NewGlobalRef, we would get >> > > automatically: >> > > > > >> > > > > FATAL ERROR in native method: NewGlobalRef:Return >> > is NULL >> > > > > at >> > > > >> > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >> > > > Method) >> > > > > >> > > > > at >> > > > > >> > > > >> > > >> > >> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >> > > > >> > > > > >> > > > > >> > > > > >> > > > > Again as we port and simplify more tests (I'll only >> > do the >> > > locks >> > > > for now >> > > > > and we can figure out the next steps as start >> > working on >> > > moving >> > > > tests >> > > > > out of vmTestbase), >> > > > > we can add, if needed, other exception handlers >> > that don't >> > > throw >> > > > or do >> > > > > other things depending on the JNI method outputs. >> > > > > >> > > > > >> > > > > 2. Make the local SafeJNIEnv a pointer called >> > env so >> > > that the >> > > > change is >> > > > > less disruptive. All the env->op() calls will >> > remain >> > > and only >> > > > the local >> > > > > error checking will be removed. >> > > > > >> > > > > >> > > > > Done, I used a unique_ptr to make the object >> > > > created/destroyed/available >> > > > > as a pointer do-able in one line: >> > > > > std::unique_ptr env(new >> > SafeJNIEnv(jni_env)); >> > > > > >> > > > > and then you can see that, as you mentioned, the >> > disruption to >> > > > the code >> > > > > is much less: >> > > > > >> > > > >> > > >> > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > >> > > > > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > > >> > > > > Basically the tests now become internal to the >> > SafeJNIEnv >> > > and the >> > > > code >> > > > > now only contains the JNI calls happening but we >> > are protected >> > > > and will >> > > > > fail any test that has an exception or a NULL >> > return for the >> > > > call. Of >> > > > > course, this is not 100% proof in terms of not >> > having any >> > > error >> > > > handling >> > > > > in the test but in some cases like this, the new >> > code seems to >> > > > just work >> > > > > better: >> > > > > >> > > > > >> > > > >> > > >> > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > >> > > > > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > > >> > > > > >> > > > > >> > > > > The switch from, e.g., checking NULL returns to >> > > checking for >> > > > pending >> > > > > exceptions, need to be sure that the JNI >> operations >> > > clearly >> > > > specify >> > > > > that >> > > > > NULL implies there will be an exception >> > pending. This >> > > change >> > > > may be an >> > > > > issue for static code analysis if not smart >> > enough to >> > > > understand the >> > > > > RAII wrappers. >> > > > > >> > > > > >> > > > > Agreed, I fixed it to be more strict and say: in >> > normal test >> > > > handling, >> > > > > the JNI calls should never return NULL or throw an >> > > exception. This >> > > > > should hold for tests I imagine but if not we can >> add a >> > > different >> > > > call >> > > > > verifier as we go. >> > > > > >> > > > > >> > > > > Thanks, >> > > > > David >> > > > > >> > > > > > Jc >> > > > > >> > > > > >> > > > > >> > > > > Let me know what you all think. When talking about >> it a >> > > bit, I had >> > > > > gotten some interest to see what it would look >> > like. Here >> > > it is >> > > > :-). Now >> > > > > if it is not wanted like I said, I can backtrack >> > and just >> > > put the >> > > > error >> > > > > checks after each JNI call for all the tests as we >> are >> > > porting them. >> > > > > Jc >> > > > >> > > > >> > > > >> > > > -- >> > > > >> > > > Thanks, >> > > > Jc >> > > >> > > >> > > >> > > -- >> > > >> > > Thanks, >> > > Jc >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Thu Sep 27 04:47:20 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 26 Sep 2018 21:47:20 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> Message-ID: <09AF0615-DC28-40AA-8003-175F35D676F2@oracle.com> Sorry for being late to the game. Can I request a helpful comment in SafeJNIEnv.hpp describing what its purpose is? Also, I don?t necessarily have a better suggestion (and don?t consider this blocking), but Is there another word than ?Safe? to describe this wrapper? ?Checked?? ExceptionChecking? Just something to consider. Cheers, Mikael > On Sep 26, 2018, at 8:52 PM, JC Beyler wrote: > > Ping on this, anybody have time to do a review and give a LGTM? Or David if you have time and will to provide an explicit LGTM :) > > Thanks, > Jc > > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > wrote: > Hi David, > > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting for an explicit LGTM from you or from someone else on this list to do a review. > > Thanks again for your help, > Jc > > On Sun, Sep 23, 2018 at 9:22 AM David Holmes > wrote: > Hi Jc, > > I don't think it is an issue for this to go ahead. If the static > analysis tool has an issue then we can either find out how to teach it > about this code structure, or else flag the issues as false positives. > I'd be relying on one of the serviceability team here to handle that if > the problem arises. > > Thanks, > David > > On 23/09/2018 12:17 PM, JC Beyler wrote: > > Hi David, > > > > No worries with the time to answer; I appreciate the review! > > > > That's a fair point. Is it possible to "describe" to the static analysis > > tool to "trust" calls made in the SafeJNIEnv class? > > > > Otherwise, do you have any idea on how to go forward? For what it's > > worth, this current webrev does not try to replace exception checking > > with the SafeJNIEnv (it actually adds it), so for now the > > question/solution could be delayed. I could continue working on this in > > the scope of both the nsk/gc/lock/jniref code base and the NSK_VERIFIER > > macro removal and we can look at how to tackle the cases where the tests > > are actually calling exception checking (I know my heapmonitor does for > > example). > > > > Let me know what you think and thanks for the review, > > Jc > > > > > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > > >> wrote: > > > > Hi Jc, > > > > Sorry for the delay on getting back to this but I'm travelling at the > > moment. > > > > This looks quite neat. Thanks also to Alex for all the suggestions. > > > > My only remaining concern is that static analysis tools may not like > > this because they may not be able to determine that we won't make > > subsequent JNI calls when an exception happens in the first. That's not > > a reason not to do this of course, just flagging that we may have to do > > something to deal with that problem. > > > > Thanks, > > David > > > > On 20/09/2018 11:56 AM, JC Beyler wrote: > > > Hi Alex, > > > > > > Done here, thanks for the review: > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > Thanks again! > > > Jc > > > > > > > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > > > > > > > > >>> wrote: > > > > > > Hi Jc, > > > > > > Looks good to me. > > > A minor note: > > > - I'd move ErrorHandler typedef to SafeJNIEnv class to avoid > > global > > > namespece pollution (ErrorHandler is too generic name). > > > > > > --alex > > > > > > On 09/19/2018 15:56, JC Beyler wrote: > > > > Hi Alex, > > > > > > > > I've updated the webrev to: > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > That webrev has the code that is shown here in snippets. > > > > > > > > > > > > Thanks for the reviews, I've relatively followed your reviews > > > except for > > > > one detail due to me wanting to handle the NSK_JNI_VERIFY > > macros via > > > > this system as well later down the road. For an example: > > > > > > > > We currently have in the code: > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > NSK_CPP_STUB2(GetObjectClass, > > > > pEnv, mhToCall)) != NULL) ) > > > > > > > > 1) The NSK_CPP_STUB2 is trivially removed with a refactor > > > (JDK-8210728) > > > > > to: > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > pEnv->GetObjectClass(pEnv, > > > > mhToCall)) != NULL) ) > > > > > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove it to and it > > > becomes via > > > > this wrapping of JNIEnv: > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, mhToCall)) ) > > > > > > > > 3) Then, via removing the assignment, we'd arrive to a: > > > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > > > if (!mhClass) > > > > > > > > Without any loss of checking for failures, etc. > > > > > > > > So that is my motivation for most of this work with a concrete > > > example > > > > (hopefully it helps drive this conversation). > > > > > > > > I inlined my answers here, let me know what you think. > > > > > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > > > > > >> > > > > > > > > > > > > >>>> wrote: > > > > > > > > Hi Jc, > > > > > > > > Updated tests looks good. > > > > Some notes about implementation. > > > > > > > > - FatalOnException implements both verification and error > > > handling > > > > It would be better to separate them (and this makes > > easy to > > > implement > > > > error handling different from JNIEnv::FatalError). > > > > The simplest way is to define error handler as > > > > class SafeJNIEnv { > > > > public: > > > > typedef void (*ErrorHandler)(JNIEnv *env, const > > char* > > > errorMsg); > > > > // error handler which terminates jvm by using > > FatalError() > > > > static void FatalError(JNIEnv *env, const char > > *errrorMsg); > > > > > > > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler > > errorHandler = > > > > FatalError); > > > > (SafeJNIEnv methods should create FatalOnException objects > > > passing > > > > errorHandler) > > > > > > > > > > > > > > > > Agreed, I tried to keep the code simple. The concepts you > > talk about > > > > here are generally what I reserve for when I need it (ie > > > extensions and > > > > handling new cases). But a lot are going to be needed soon > > so I > > > think it > > > > is a good time to iron the code out now on this "simple" > > webrev. > > > > > > > > So done for this. > > > > > > > > > > > > > > > > - FatalOnException is used in SafeJNIEnv methods as > > > > FatalOnException marker(this, "msg"); > > > > ret = > > > > (optional)marker.check_for_null(ret); > > > > return ret; > > > > But actually I'd call it something like > > JNICallResultVerifier and > > > > create > > > > the object after JNI call. like > > > > ret = > > > > JNICallResultVerifier(this, "msg") > > > > (optional).notNull(ret); > > > > return ret; > > > > or even (if you like such syntax sugar) you can define > > > > template > > > > T resultNotNull(T result) { > > > > notNull(result); > > > > return result; > > > > } > > > > and do > > > > ret = > > > > return JNICallResultVerifier(this, > > "msg").resultNotNull(ret); > > > > > > > > > > > > So I renamed FatalOnException to now being JNIVerifier. > > > > > > > > Though I like it, I don't think we can do it, except if we > > do it > > > > slightly differently: > > > > I'm trying to solve two problems with one stone: > > > > - How to check for returns of JNI calls in the way that is > > > done here > > > > - How to remove NSK_JNI_VERIFY* (from > > nsk/share/jni/jni_tools) > > > > > > > > However, the NSK_JNI_VERIFY need to start a tracing system > > before > > > the > > > > call to JNI, so it won't work this way. (Side question > > would be > > > do we > > > > still care about the tracing in NSK_JNI_VERIFY, if we > > don't then > > > your > > > > solution works well in most situations). > > > > > > > > My vision or intuition is that we would throw a template > > at some > > > point > > > > on SafeJNIEnv to handle both cases and have JNIVerifier > > become a > > > > specialization in certain cases and something different > > for the > > > > NSK_JNI_VERIFY case (or have a different constructor to enable > > > tracing). > > > > But for now, I offer the implementation that does: > > > > > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > > > > JNIVerifier marker(this, "GetObjectClass"); > > > > return marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > > > } > > > > > > > > and: > > > > > > > > void SafeJNIEnv::SetObjectField(jobject obj, jfieldID > > field, jobject > > > > value) { > > > > JNIVerifier<> marker(this, "SetObjectField"); > > > > _jni_env->SetObjectField(obj, field, value); > > > > } > > > > > > > > > > > > > > > > > > > > - you added #include in the test (and you have to > > > add it to > > > > every test). > > > > It would be simpler to add the include to > > SafeJNIEnv.hpp and > > > define > > > > typedef std::unique_ptr SafeJNIEnvPtr; > > > > Then each in the test methods: > > > > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > > > > or you can add > > > > static SafeJNIEnv::SafeJNIEnvPtr wrap(JNIEnv* jni_env, > > > ErrorHandler > > > > errorHandler = fatalError) > > > > and get > > > > SafeJNIEnvPtr env = SafeJNIEnv::wrap(jni_env); > > > > > > > > > > > > Done, I like that, even less code change to tests then. > > > > > > > > > > > > > > > > - it would be better to wrap internal classes > > > (FatalOnException) into > > > > unnamed namespace - this helps to avoid conflicts with > > other > > > classes) > > > > > > > > - FatalOnException::check_for_null(void* ptr) > > > > should be > > > > FatalOnException::check_for_null(const void* ptr) > > > > And calling the method you don't need reinterpret_cast > > > > > > > > > > > > Also done, it got renamed to ResultNotNull, is using a > > template > > > now, but > > > > agreed, that worked. > > > > Thanks again for the review, > > > > Jc > > > > > > > > > > > > --alex > > > > > > > > > > > > On 09/18/2018 11:07, JC Beyler wrote: > > > > > Hi David, > > > > > > > > > > Thanks for the quick review and thoughts. I have > > now a new > > > > version here > > > > > that addresses your comments: > > > > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > I've also inlined my answers/comments. > > > > > > > > > > > > > > > > > > > > > I've slowly started working on JDK-8191519 > > > > > > > > >. > > > > However before > > > > > > starting to really refactor all the tests, I > > > thought I'd > > > > get a few > > > > > > opinions. I am working on internalizing the > > error > > > handling > > > > of JNI > > > > > calls > > > > > > via a SafeJNIEnv class that redefines all > > the JNI > > > calls to > > > > add an > > > > > error > > > > > > checker. > > > > > > > > > > > > The advantage is that the test code will > > look and > > > feel like > > > > > normal JNI > > > > > > code and calls but will have the checks we > > want to have > > > > for our > > > > > tests. > > > > > > > > > > Not sure I get that. Normal JNI code has to > > check for > > > > errors/exceptions > > > > > after every call. The tests need those checks too. > > > Today they are > > > > > explicit, with this change they become > > implicit. Not sure > > > > what we are > > > > > gaining here ?? > > > > > > > > > > > > > > > In my humble opinion, having the error checking out > > of the way > > > > allows > > > > > the code reader to concentrate on the JNI code while > > > maintaining > > > > error > > > > > checking. We use something similar internally, so > > perhaps I'm > > > > biased to > > > > > it :-). > > > > > If this is not a desired/helpful "feature" to simplify > > > tests in > > > > general, > > > > > I will backtrack it and just add the explicit tests > > to the > > > native > > > > code > > > > > of the locks for the fix > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > > > > > > > Let me however try to make my case and let me know what > > > you all > > > > think! > > > > > > > > > > > > > > > > If agreed with this, we can augment the > > SafeJNIEnv > > > class > > > > as needed. > > > > > > Also, if the tests require something else > > than fatal > > > > errors, we > > > > > can add > > > > > > a different marker and make it a parameter > > to the > > > base class. > > > > > > > > > > > > Webrev: > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > > > Let me know what you think, > > > > > > > > > > Two initial suggestions: > > > > > > > > > > 1. FatalOnException should be constructed with a > > > description > > > > string so > > > > > that it can report the failing operation when > > calling > > > > FatalError rather > > > > > than the general "Problem with a JNI call". > > > > > > > > > > > > > > > Agreed with you, the new webrev produces: > > > > > > > > > > FATAL ERROR in native method: GetObjectClass > > > > > at > > > > > > > > > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > > > > at > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > Method) > > > > > at > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > at > > > > > > > > > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > > > > at > > > > > > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > > > > > > > > > > and for a return NULL in NewGlobalRef, we would get > > > automatically: > > > > > > > > > > FATAL ERROR in native method: NewGlobalRef:Return > > is NULL > > > > > at > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > Method) > > > > > > > > > > at > > > > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > > > > > > > > > > > > > > > > Again as we port and simplify more tests (I'll only > > do the > > > locks > > > > for now > > > > > and we can figure out the next steps as start > > working on > > > moving > > > > tests > > > > > out of vmTestbase), > > > > > we can add, if needed, other exception handlers > > that don't > > > throw > > > > or do > > > > > other things depending on the JNI method outputs. > > > > > > > > > > > > > > > 2. Make the local SafeJNIEnv a pointer called > > env so > > > that the > > > > change is > > > > > less disruptive. All the env->op() calls will > > remain > > > and only > > > > the local > > > > > error checking will be removed. > > > > > > > > > > > > > > > Done, I used a unique_ptr to make the object > > > > created/destroyed/available > > > > > as a pointer do-able in one line: > > > > > std::unique_ptr env(new > > SafeJNIEnv(jni_env)); > > > > > > > > > > and then you can see that, as you mentioned, the > > disruption to > > > > the code > > > > > is much less: > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Basically the tests now become internal to the > > SafeJNIEnv > > > and the > > > > code > > > > > now only contains the JNI calls happening but we > > are protected > > > > and will > > > > > fail any test that has an exception or a NULL > > return for the > > > > call. Of > > > > > course, this is not 100% proof in terms of not > > having any > > > error > > > > handling > > > > > in the test but in some cases like this, the new > > code seems to > > > > just work > > > > > better: > > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The switch from, e.g., checking NULL returns to > > > checking for > > > > pending > > > > > exceptions, need to be sure that the JNI operations > > > clearly > > > > specify > > > > > that > > > > > NULL implies there will be an exception > > pending. This > > > change > > > > may be an > > > > > issue for static code analysis if not smart > > enough to > > > > understand the > > > > > RAII wrappers. > > > > > > > > > > > > > > > Agreed, I fixed it to be more strict and say: in > > normal test > > > > handling, > > > > > the JNI calls should never return NULL or throw an > > > exception. This > > > > > should hold for tests I imagine but if not we can add a > > > different > > > > call > > > > > verifier as we go. > > > > > > > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > Let me know what you all think. When talking about it a > > > bit, I had > > > > > gotten some interest to see what it would look > > like. Here > > > it is > > > > :-). Now > > > > > if it is not wanted like I said, I can backtrack > > and just > > > put the > > > > error > > > > > checks after each JNI call for all the tests as we are > > > porting them. > > > > > Jc > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Sep 27 05:16:42 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 26 Sep 2018 22:16:42 -0700 (PDT) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <8f78ff9f-a548-5d5f-bdb0-f366877d2226@oracle.com> Message-ID: <8ccc1a0e-d253-4fbd-9d0b-d334cd8b7bb1@default> Can I get one more review from a (R)eviewer please ? Thanks, Sharath -----Original Message----- From: Sharath Ballal Sent: Wednesday, September 26, 2018 9:57 AM To: Jini Susan George; serviceability-dev Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Thanks for the review Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Wednesday, September 26, 2018 9:42 AM To: Sharath Ballal; serviceability-dev Subject: Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Looks good to me. Thanks, Jini. On 9/24/2018 9:19 AM, Sharath Ballal wrote: > Hi, > > Pls review this test fix to add "-Xmx512m" to SA tests which create > either core file or heap dump, to avoid timeout due to large heap sizes. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > SA tests passed on Mach5 run. > > Thanks, > > Sharath > From gary.adams at oracle.com Thu Sep 27 11:39:26 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 27 Sep 2018 07:39:26 -0400 Subject: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)" In-Reply-To: <14e03139-177f-e04d-2640-ad88ff6d413f@oracle.com> References: <5BAB9DCE.9040505@oracle.com> <404373b8-6315-8f0c-80ed-ea05c43fea30@oracle.com> <5BABCACC.6080204@oracle.com> <14e03139-177f-e04d-2640-ad88ff6d413f@oracle.com> Message-ID: <5BACC16E.5090406@oracle.com> Patch attached. Ran another 1000 clean testruns with the sleep(1) pauses. Restored the sleep(100) for the final patch. On 9/26/18, 2:12 PM, Chris Plummer wrote: > On 9/26/18 11:07 AM, Gary Adams wrote: >> On 9/26/18, 1:40 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> Should the following comment come first, not after the join() call: >>> >>> 115 mt.join(); >>> 116 // Wait till the other thread completes its execution. >> I'll move the comment up. >>> >>> Rather than using JVMTI to detect if the field is suspended, >>> couldn't you have just set a static variable in >>> callbackFieldAccess() and check it from isSuspended()? >> All of the other native calls take a thread and operate on it. >> It seemed reasonable to use the same check that popThreadFrame used. >> >>> >>> Before doing the fix, did you first check if the bug is easily >>> reproduced by making is sleep for 1ms instead of 100ms? >> That's how I got the problem to reproduce. >> Switching to sleep(1) got 5 failures in 300 testruns. > Ok, and I assume you then tested the fix with the 1ms sleep? If so, > then ship it. Otherwise do this testing first. > > thanks, > > Chris >>> >>> thanks, >>> >>> Chris >>> >>> On 9/26/18 7:55 AM, Gary Adams wrote: >>>> A race condition exists in hs203t003 between the main test thread and >>>> the processing in callbackFieldAccess processing. The main thread >>>> already includes a polling loop to wait for the redefine class >>>> operation >>>> to be performed, but it does not wait for the following suspend thread >>>> operation to be completed. >>>> >>>> This changeset adds an additional wait for the suspend thread to >>>> complete. >>>> It also checks the error returns from popThreadFrame and resumeThread >>>> to issue an additional error message if these native routines >>>> returned an error. >>>> >>>> Webrev: http://cr.openjdk.java.net/~gadams/8210984/webrev.00/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210984 >>> >>> >>> >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8210984.patch URL: From gary.adams at oracle.com Thu Sep 27 12:05:35 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 27 Sep 2018 08:05:35 -0400 Subject: nsk/jvmti/scenarios/hotswap bugs on the ProblemList Message-ID: <5BACC78F.3080502@oracle.com> While looking at some other hotswap tests, I noticed 2 tests on the ProblemList. I'm attempting some runs with the tests removed from the list to try and reproduce the errors locally. Issues: https://bugs.openjdk.java.net/browse/JDK-6813266 hs204t001 https://bugs.openjdk.java.net/browse/JDK-8204506 hs102t002 diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -185,8 +185,6 @@ vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted004/TestDescription.java 7013634,6606767 generic-all vmTestbase/nsk/jvmti/ThreadStart/threadstart001/TestDescription.java 8016181 generic-all vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java 8173658 generic-all -vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t002/TestDescription.java 8204506,8203350 generic-all -vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java 6813266 generic-all vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/TestDescription.java 8051349 generic-all vmTestbase/nsk/jvmti/AttachOnDemand/attach034/TestDescription.java 8042145 generic-all vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java 8202971 generic-all It's odd that the JDK-6813266 is in the ProblemList, when the bug was closed as not reproducible. I'm wondering if it was quarantined when the bug was closed. For JDK-8204506, it's not clear if this is a graal only bug and only needs to be listed in ProblemList-graal.txt. From gary.adams at oracle.com Thu Sep 27 12:18:56 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 27 Sep 2018 08:18:56 -0400 Subject: JDK-8203350: Crash in vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java Message-ID: <5BACCAB0.1050806@oracle.com> I've been unsuccessful trying to reproduce the failure in hs201t002. Issue: https://bugs.openjdk.java.net/browse/JDK-8203350 Colleen made a comment on the bug that the reference from hs201t002a to class hs201t002 might be an issue for the redefined class. I found in test hs201t001 that an intentional reference before entering hs201t001a.doInit() is made to avoid that classloader operation. It's not clear to me why that was done, but the same workaround could be used in hs201t002a, if it would make the test more robust. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java @@ -26,6 +26,7 @@ public class hs201t002a extends Exception { public hs201t002a () { + System.out.println("Current step: " + hs201t002.currentStep); // Avoid calling classloader to find hs201t002 in doInit() doInit(); } From david.holmes at oracle.com Thu Sep 27 13:00:13 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 09:00:13 -0400 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> Message-ID: LGTM :) Thanks, David On 26/09/2018 11:51 PM, JC Beyler wrote: > Hi all, > > Anybody on the hotspot-dev list have any comments or a LGTM? > > Thanks! > Jc > > On Tue, Sep 25, 2018 at 10:56 AM Alex Menkov > wrote: > >> +1 >> >> --alex >> >> On 09/24/2018 11:40, Igor Ignatyev wrote: >>> (cc-ing hotspot-dev alias) >>> >>> Hi Jc, >>> >>> the fix looks good to me. don't forget to clean up nsk/share/jni/README >> at the end. >>> >>> Thanks, >>> -- Igor >>> >>>> On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: >>>> >>>> Hi all, >>>> >>>> As the tests have become C++ tests, the NSK_CPP_STUBS are no longer >> needed. I did two awk scripts to remove them and will be rolling them out >> in 50 file max reviews to streamline the reviews for the reviewers. >>>> >>>> So here is the first which handles all the cases outside of the jvmti >> subfolder: >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ < >> http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 < >> https://bugs.openjdk.java.net/browse/JDK-8211036> >>>> >>>> The bug contains information on the two scripts I used. >>>> >>>> Thanks, >>>> Jc >>> >> > > From david.holmes at oracle.com Thu Sep 27 13:03:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 09:03:12 -0400 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> Message-ID: <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> Sorry Jc, I thought my LGTM was implicit. :) Thanks, David On 26/09/2018 11:52 PM, JC Beyler wrote: > Ping on this, anybody have time to do a review and give a LGTM? Or David > if you have time and will to provide an explicit LGTM :) > > Thanks, > Jc > > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > wrote: > > Hi David, > > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting > for an explicit LGTM from you or from someone else on this list to > do a review. > > Thanks again for your help, > Jc > > On Sun, Sep 23, 2018 at 9:22 AM David Holmes > > wrote: > > Hi Jc, > > I don't think it is an issue for this to go ahead. If the static > analysis tool has an issue then we can either find out how to > teach it > about this code structure, or else flag the issues as false > positives. > I'd be relying on one of the serviceability team here to handle > that if > the problem arises. > > Thanks, > David > > On 23/09/2018 12:17 PM, JC Beyler wrote: > > Hi David, > > > > No worries with the time to answer; I appreciate the review! > > > > That's a fair point. Is it possible to "describe" to the > static analysis > > tool to "trust" calls made in the SafeJNIEnv class? > > > > Otherwise, do you have any idea on how to go forward? For > what it's > > worth, this current webrev does not try to replace exception > checking > > with the SafeJNIEnv (it actually adds it), so for now the > > question/solution could be delayed. I could continue working > on this in > > the scope of both the nsk/gc/lock/jniref code base and the > NSK_VERIFIER > > macro removal and we can look at how to tackle the cases > where the tests > > are actually calling exception checking (I know my > heapmonitor does for > > example). > > > > Let me know what you think and thanks for the review, > > Jc > > > > > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?Sorry for the delay on getting back to this but I'm > travelling at the > >? ? ?moment. > > > >? ? ?This looks quite neat. Thanks also to Alex for all the > suggestions. > > > >? ? ?My only remaining concern is that static analysis tools > may not like > >? ? ?this because they may not be able to determine that we > won't make > >? ? ?subsequent JNI calls when an exception happens in the > first. That's not > >? ? ?a reason not to do this of course, just flagging that we > may have to do > >? ? ?something to deal with that problem. > > > >? ? ?Thanks, > >? ? ?David > > > >? ? ?On 20/09/2018 11:56 AM, JC Beyler wrote: > >? ? ? > Hi Alex, > >? ? ? > > >? ? ? > Done here, thanks for the review: > >? ? ? > > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > >? ? ? > >? ? ? > > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? > > >? ? ? > Thanks again! > >? ? ? > Jc > >? ? ? > > >? ? ? > > >? ? ? > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > >? ? ? > > > >? ? ? > > >? ? ? >>> wrote: > >? ? ? > > >? ? ? >? ? ?Hi Jc, > >? ? ? > > >? ? ? >? ? ?Looks good to me. > >? ? ? >? ? ?A minor note: > >? ? ? >? ? ?- I'd move ErrorHandler typedef to SafeJNIEnv > class to avoid > >? ? ?global > >? ? ? >? ? ?namespece pollution (ErrorHandler is too generic > name). > >? ? ? > > >? ? ? >? ? ?--alex > >? ? ? > > >? ? ? >? ? ?On 09/19/2018 15:56, JC Beyler wrote: > >? ? ? >? ? ? > Hi Alex, > >? ? ? >? ? ? > > >? ? ? >? ? ? > I've updated the webrev to: > >? ? ? >? ? ? > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > > >? ? ? >? ? ? > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? >? ? ? > > >? ? ? >? ? ? > That webrev has the code that is shown here in > snippets. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Thanks for the reviews, I've relatively > followed your reviews > >? ? ? >? ? ?except for > >? ? ? >? ? ? > one detail due to me wanting to handle the > NSK_JNI_VERIFY > >? ? ?macros via > >? ? ? >? ? ? > this system as well later down the road. For an > example: > >? ? ? >? ? ? > > >? ? ? >? ? ? > We currently have in the code: > >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > >? ? ?NSK_CPP_STUB2(GetObjectClass, > >? ? ? >? ? ? > pEnv, mhToCall)) != NULL) ) > >? ? ? >? ? ? > > >? ? ? >? ? ? > 1) The NSK_CPP_STUB2 is trivially removed with > a refactor > >? ? ? >? ? ?(JDK-8210728) > >? ? ? >? ? ? > > ?to: > >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > >? ? ?pEnv->GetObjectClass(pEnv, > >? ? ? >? ? ? > mhToCall)) != NULL) ) > >? ? ? >? ? ? > > >? ? ? >? ? ? > 2) Then the NSK_JNI_VERIFY, I'd like to remove > it to and it > >? ? ? >? ? ?becomes via > >? ? ? >? ? ? > this wrapping of JNIEnv: > >? ? ? >? ? ? > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, > mhToCall)) ) > >? ? ? >? ? ? > > >? ? ? >? ? ? > 3) Then, via removing the assignment, we'd > arrive to a: > >? ? ? >? ? ? > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > >? ? ? >? ? ? > if (!mhClass) > >? ? ? >? ? ? > > >? ? ? >? ? ? > Without any loss of checking for failures, etc. > >? ? ? >? ? ? > > >? ? ? >? ? ? > So that is my motivation for most of this work > with a concrete > >? ? ? >? ? ?example > >? ? ? >? ? ? > (hopefully it helps drive this conversation). > >? ? ? >? ? ? > > >? ? ? >? ? ? > I inlined my answers here, let me know?what you > think. > >? ? ? >? ? ? > > >? ? ? >? ? ? > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > >? ? ? >? ? ? > > > >? ? ? > >> > >? ? ? >? ? ? > > >? ? ? > > >? ? ? >? ? ? > >? ? ? >>>> wrote: > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?Hi Jc, > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?Updated tests looks good. > >? ? ? >? ? ? >? ? ?Some notes about implementation. > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?- FatalOnException implements both > verification and error > >? ? ? >? ? ?handling > >? ? ? >? ? ? >? ? ?It would be better to separate them (and > this makes > >? ? ?easy to > >? ? ? >? ? ?implement > >? ? ? >? ? ? >? ? ?error handling different from > JNIEnv::FatalError). > >? ? ? >? ? ? >? ? ?The simplest way is to define error handler as > >? ? ? >? ? ? >? ? ?class SafeJNIEnv { > >? ? ? >? ? ? >? ? ?public: > >? ? ? >? ? ? >? ? ? ? ? ?typedef void (*ErrorHandler)(JNIEnv > *env, const > >? ? ?char* > >? ? ? >? ? ?errorMsg); > >? ? ? >? ? ? >? ? ? ? ? ?// error handler which terminates jvm > by using > >? ? ?FatalError() > >? ? ? >? ? ? >? ? ? ? ? ?static void FatalError(JNIEnv *env, > const char > >? ? ?*errrorMsg); > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? ? ? ?SafeJNIEnv(JNIEnv* jni_env, ErrorHandler > >? ? ?errorHandler = > >? ? ? >? ? ? >? ? ?FatalError); > >? ? ? >? ? ? >? ? ?(SafeJNIEnv methods should create > FatalOnException objects > >? ? ? >? ? ?passing > >? ? ? >? ? ? >? ? ?errorHandler) > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Agreed, I tried to keep the code simple. The > concepts you > >? ? ?talk about > >? ? ? >? ? ? > here are generally what I reserve for when I > need it (ie > >? ? ? >? ? ?extensions and > >? ? ? >? ? ? > handling new cases). But a lot are going to be > needed soon > >? ? ?so I > >? ? ? >? ? ?think it > >? ? ? >? ? ? > is a good time to iron the code out now on this > "simple" > >? ? ?webrev. > >? ? ? >? ? ? > > >? ? ? >? ? ? > So done for this. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?- FatalOnException is used in SafeJNIEnv > methods as > >? ? ? >? ? ? >? ? ? ? ?FatalOnException marker(this, "msg"); > >? ? ? >? ? ? >? ? ? ? ?ret = > >? ? ? >? ? ? >? ? ? ? ?(optional)marker.check_for_null(ret); > >? ? ? >? ? ? >? ? ? ? ?return ret; > >? ? ? >? ? ? >? ? ?But actually I'd call it something like > >? ? ?JNICallResultVerifier and > >? ? ? >? ? ? >? ? ?create > >? ? ? >? ? ? >? ? ?the object after JNI call. like > >? ? ? >? ? ? >? ? ? ? ?ret = > >? ? ? >? ? ? >? ? ? ? ?JNICallResultVerifier(this, "msg") > >? ? ? >? ? ? >? ? ? ? ? ?(optional).notNull(ret); > >? ? ? >? ? ? >? ? ? ? ?return ret; > >? ? ? >? ? ? >? ? ?or even (if you like such syntax sugar) you > can define > >? ? ? >? ? ? >? ? ? ? ?template > >? ? ? >? ? ? >? ? ? ? ?T resultNotNull(T result) { > >? ? ? >? ? ? >? ? ? ? ? ? ?notNull(result); > >? ? ? >? ? ? >? ? ? ? ? ? ?return result; > >? ? ? >? ? ? >? ? ? ? ?} > >? ? ? >? ? ? >? ? ?and do > >? ? ? >? ? ? >? ? ? ? ?ret = > >? ? ? >? ? ? >? ? ? ? ?return JNICallResultVerifier(this, > >? ? ?"msg").resultNotNull(ret); > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > So I renamed FatalOnException to now being > JNIVerifier. > >? ? ? >? ? ? > > >? ? ? >? ? ? > Though I like it, I don't think we can do it, > except if we > >? ? ?do it > >? ? ? >? ? ? > slightly differently: > >? ? ? >? ? ? > I'm trying to solve two problems with one stone: > >? ? ? >? ? ? >? ? ?- How to check for returns of JNI calls in > the way that is > >? ? ? >? ? ?done here > >? ? ? >? ? ? >? ? ?- How to remove NSK_JNI_VERIFY* (from > >? ? ?nsk/share/jni/jni_tools) > >? ? ? >? ? ? > > >? ? ? >? ? ? > However, the NSK_JNI_VERIFY need to start a > tracing system > >? ? ?before > >? ? ? >? ? ?the > >? ? ? >? ? ? > call to JNI, so it won't work this way. (Side > question > >? ? ?would be > >? ? ? >? ? ?do we > >? ? ? >? ? ? > still care about the tracing in NSK_JNI_VERIFY, > if we > >? ? ?don't then > >? ? ? >? ? ?your > >? ? ? >? ? ? > solution works well in most situations). > >? ? ? >? ? ? > > >? ? ? >? ? ? > My vision or intuition is that we would throw a > template > >? ? ?at some > >? ? ? >? ? ?point > >? ? ? >? ? ? > on SafeJNIEnv to handle both cases and have > JNIVerifier > >? ? ?become a > >? ? ? >? ? ? > specialization in certain cases and something > different > >? ? ?for the > >? ? ? >? ? ? > NSK_JNI_VERIFY case (or have a different > constructor to enable > >? ? ? >? ? ?tracing). > >? ? ? >? ? ? > But for now, I offer the implementation that does: > >? ? ? >? ? ? > > >? ? ? >? ? ? > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > >? ? ? >? ? ? >? ? JNIVerifier marker(this, > "GetObjectClass"); > >? ? ? >? ? ? >? ? return > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > >? ? ? >? ? ? > } > >? ? ? >? ? ? > > >? ? ? >? ? ? > and: > >? ? ? >? ? ? > > >? ? ? >? ? ? > void SafeJNIEnv::SetObjectField(jobject obj, > jfieldID > >? ? ?field, jobject > >? ? ? >? ? ? > value) { > >? ? ? >? ? ? >? ? JNIVerifier<> marker(this, "SetObjectField"); > >? ? ? >? ? ? >? ? _jni_env->SetObjectField(obj, field, value); > >? ? ? >? ? ? > } > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?- you added #include in the test > (and you have to > >? ? ? >? ? ?add it to > >? ? ? >? ? ? >? ? ?every test). > >? ? ? >? ? ? >? ? ?It would be simpler to add the include to > >? ? ?SafeJNIEnv.hpp and > >? ? ? >? ? ?define > >? ? ? >? ? ? >? ? ?typedef std::unique_ptr > SafeJNIEnvPtr; > >? ? ? >? ? ? >? ? ?Then each in the test methods: > >? ? ? >? ? ? >? ? ? ? ?SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > >? ? ? >? ? ? >? ? ?or you can add > >? ? ? >? ? ? >? ? ?static SafeJNIEnv::SafeJNIEnvPtr > wrap(JNIEnv* jni_env, > >? ? ? >? ? ?ErrorHandler > >? ? ? >? ? ? >? ? ?errorHandler = fatalError) > >? ? ? >? ? ? >? ? ?and get > >? ? ? >? ? ? >? ? ? ? ?SafeJNIEnvPtr env = > SafeJNIEnv::wrap(jni_env); > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Done, I like that, even less code change to > tests then. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?- it would be better to wrap internal classes > >? ? ? >? ? ?(FatalOnException) into > >? ? ? >? ? ? >? ? ?unnamed namespace - this helps to avoid > conflicts with > >? ? ?other > >? ? ? >? ? ?classes) > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?- FatalOnException::check_for_null(void* ptr) > >? ? ? >? ? ? >? ? ?should be > >? ? ? >? ? ? >? ? ?FatalOnException::check_for_null(const > void* ptr) > >? ? ? >? ? ? >? ? ?And calling the method you don't need > reinterpret_cast > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Also done, it got renamed to ResultNotNull, is > using a > >? ? ?template > >? ? ? >? ? ?now, but > >? ? ? >? ? ? > agreed, that worked. > >? ? ? >? ? ? > Thanks again for the review, > >? ? ? >? ? ? > Jc > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?--alex > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ?On 09/18/2018 11:07, JC Beyler wrote: > >? ? ? >? ? ? >? ? ? > Hi David, > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Thanks for the quick review and > thoughts. I have > >? ? ?now a new > >? ? ? >? ? ? >? ? ?version here > >? ? ? >? ? ? >? ? ? > that addresses your comments: > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Webrev: > >? ? ? > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > >? ? ? ? > >? ? ? >? ? ? >? ? ? > > >? ? ? > >? ? ? >? ? ? >? ? ? > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > I've also inlined my answers/comments. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? > I've slowly started working on > JDK-8191519 > >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ?. > >? ? ? >? ? ? >? ? ?However before > >? ? ? >? ? ? >? ? ? >? ? ? > starting to really refactor all > the tests, I > >? ? ? >? ? ?thought I'd > >? ? ? >? ? ? >? ? ?get a few > >? ? ? >? ? ? >? ? ? >? ? ? > opinions.?I am working on > internalizing the > >? ? ?error > >? ? ? >? ? ?handling > >? ? ? >? ? ? >? ? ?of JNI > >? ? ? >? ? ? >? ? ? >? ? ?calls > >? ? ? >? ? ? >? ? ? >? ? ? > via a SafeJNIEnv class that > redefines all > >? ? ?the JNI > >? ? ? >? ? ?calls to > >? ? ? >? ? ? >? ? ?add an > >? ? ? >? ? ? >? ? ? >? ? ?error > >? ? ? >? ? ? >? ? ? >? ? ? > checker. > >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? > The advantage is that the test > code will > >? ? ?look and > >? ? ? >? ? ?feel like > >? ? ? >? ? ? >? ? ? >? ? ?normal JNI > >? ? ? >? ? ? >? ? ? >? ? ? > code and calls but will have the > checks we > >? ? ?want to have > >? ? ? >? ? ? >? ? ?for our > >? ? ? >? ? ? >? ? ? >? ? ?tests. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ?Not sure I get that. Normal JNI code > has to > >? ? ?check for > >? ? ? >? ? ? >? ? ?errors/exceptions > >? ? ? >? ? ? >? ? ? >? ? ?after every call. The tests need > those checks too. > >? ? ? >? ? ?Today they are > >? ? ? >? ? ? >? ? ? >? ? ?explicit, with this change they become > >? ? ?implicit. Not sure > >? ? ? >? ? ? >? ? ?what we are > >? ? ? >? ? ? >? ? ? >? ? ?gaining here ?? > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > In my humble opinion, having the error > checking out > >? ? ?of the way > >? ? ? >? ? ? >? ? ?allows > >? ? ? >? ? ? >? ? ? > the code reader to concentrate on the > JNI code while > >? ? ? >? ? ?maintaining > >? ? ? >? ? ? >? ? ?error > >? ? ? >? ? ? >? ? ? > checking. We use something similar > internally, so > >? ? ?perhaps I'm > >? ? ? >? ? ? >? ? ?biased to > >? ? ? >? ? ? >? ? ? > it :-). > >? ? ? >? ? ? >? ? ? > If this is not a desired/helpful > "feature" to simplify > >? ? ? >? ? ?tests in > >? ? ? >? ? ? >? ? ?general, > >? ? ? >? ? ? >? ? ? > I will backtrack it and just add the > explicit tests > >? ? ?to the > >? ? ? >? ? ?native > >? ? ? >? ? ? >? ? ?code > >? ? ? >? ? ? >? ? ? > of the locks for the fix > >? ? ? >? ? ? >? ? ? > > > https://bugs.openjdk.java.net/browse/JDK-8191519?instead. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Let me however try to make my case and > let me know what > >? ? ? >? ? ?you all > >? ? ? >? ? ? >? ? ?think! > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? > If agreed with this, we can > augment the > >? ? ?SafeJNIEnv > >? ? ? >? ? ?class > >? ? ? >? ? ? >? ? ?as needed. > >? ? ? >? ? ? >? ? ? >? ? ? > Also, if the tests require > something else > >? ? ?than fatal > >? ? ? >? ? ? >? ? ?errors, we > >? ? ? >? ? ? >? ? ? >? ? ?can add > >? ? ? >? ? ? >? ? ? >? ? ? > a different marker and make it a > parameter > >? ? ?to the > >? ? ? >? ? ?base class. > >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? > Webrev: > >? ? ? >? ? ? > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > >? ? ? > >? ? ? > > ? > >? ? ? >? ? ? > > >? ? ? ? > >? ? ? >? ? ? >? ? ? > > >? ? ? > > ? > >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? > > ? > >? ? ? >? ? ? >? ? ? >? ? ? > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? > Let me know what you think, > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ?Two initial suggestions: > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ?1. FatalOnException should be > constructed with a > >? ? ? >? ? ?description > >? ? ? >? ? ? >? ? ?string so > >? ? ? >? ? ? >? ? ? >? ? ?that it can report the failing > operation when > >? ? ?calling > >? ? ? >? ? ? >? ? ?FatalError rather > >? ? ? >? ? ? >? ? ? >? ? ?than the general "Problem with a JNI > call". > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Agreed with you, the new webrev produces: > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > FATAL ERROR in native method: GetObjectClass > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > >? ? ? > > > > ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ? >? ? ? >? ? ?Method) > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > >? ? ? > > > > ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > >? ? ? ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > and for a return NULL in NewGlobalRef, > we would get > >? ? ? >? ? ?automatically: > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > FATAL ERROR in native method: > NewGlobalRef:Return > >? ? ?is NULL > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ? >? ? ? >? ? ?Method) > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Again as we port and simplify more tests > (I'll only > >? ? ?do the > >? ? ? >? ? ?locks > >? ? ? >? ? ? >? ? ?for now > >? ? ? >? ? ? >? ? ? > and we can figure out the next steps as > start > >? ? ?working on > >? ? ? >? ? ?moving > >? ? ? >? ? ? >? ? ?tests > >? ? ? >? ? ? >? ? ? > out of vmTestbase), > >? ? ? >? ? ? >? ? ? > we can add, if needed, other exception > handlers > >? ? ?that don't > >? ? ? >? ? ?throw > >? ? ? >? ? ? >? ? ?or do > >? ? ? >? ? ? >? ? ? > other things depending on the JNI method > outputs. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ?2. Make the local SafeJNIEnv a > pointer called > >? ? ?env so > >? ? ? >? ? ?that the > >? ? ? >? ? ? >? ? ?change is > >? ? ? >? ? ? >? ? ? >? ? ?less disruptive. All the env->op() > calls will > >? ? ?remain > >? ? ? >? ? ?and only > >? ? ? >? ? ? >? ? ?the local > >? ? ? >? ? ? >? ? ? >? ? ?error checking will be removed. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Done, I used a unique_ptr to make the object > >? ? ? >? ? ? >? ? ?created/destroyed/available > >? ? ? >? ? ? >? ? ? > as a pointer do-able in one line: > >? ? ? >? ? ? >? ? ? > std::unique_ptr env(new > >? ? ?SafeJNIEnv(jni_env)); > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > and then you can see that, as you > mentioned, the > >? ? ?disruption to > >? ? ? >? ? ? >? ? ?the code > >? ? ? >? ? ? >? ? ? > is much less: > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > ? > >? ? ? > > > > ? > >? ? ? >? ? ? > > >? ? ? > > > > ? > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > ? > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Basically the tests now become internal > to the > >? ? ?SafeJNIEnv > >? ? ? >? ? ?and the > >? ? ? >? ? ? >? ? ?code > >? ? ? >? ? ? >? ? ? > now only contains the JNI calls > happening but we > >? ? ?are protected > >? ? ? >? ? ? >? ? ?and will > >? ? ? >? ? ? >? ? ? > fail any test that has an exception or a > NULL > >? ? ?return for the > >? ? ? >? ? ? >? ? ?call. Of > >? ? ? >? ? ? >? ? ? > course, this is not 100% proof in terms > of not > >? ? ?having any > >? ? ? >? ? ?error > >? ? ? >? ? ? >? ? ?handling > >? ? ? >? ? ? >? ? ? > in the test but in some cases like this, > the new > >? ? ?code seems to > >? ? ? >? ? ? >? ? ?just work > >? ? ? >? ? ? >? ? ? > better: > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > ? > >? ? ? > > > > ? > >? ? ? >? ? ? > > >? ? ? > > > > ? > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > ? > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ?The switch from, e.g., checking NULL > returns to > >? ? ? >? ? ?checking for > >? ? ? >? ? ? >? ? ?pending > >? ? ? >? ? ? >? ? ? >? ? ?exceptions, need to be sure that the > JNI operations > >? ? ? >? ? ?clearly > >? ? ? >? ? ? >? ? ?specify > >? ? ? >? ? ? >? ? ? >? ? ?that > >? ? ? >? ? ? >? ? ? >? ? ?NULL implies there will be an exception > >? ? ?pending. This > >? ? ? >? ? ?change > >? ? ? >? ? ? >? ? ?may be an > >? ? ? >? ? ? >? ? ? >? ? ?issue for static code analysis if > not smart > >? ? ?enough to > >? ? ? >? ? ? >? ? ?understand the > >? ? ? >? ? ? >? ? ? >? ? ?RAII wrappers. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Agreed, I fixed it to be more strict and > say: in > >? ? ?normal test > >? ? ? >? ? ? >? ? ?handling, > >? ? ? >? ? ? >? ? ? > the JNI calls should never return NULL > or throw an > >? ? ? >? ? ?exception. This > >? ? ? >? ? ? >? ? ? > should hold for tests I imagine but if > not we can add a > >? ? ? >? ? ?different > >? ? ? >? ? ? >? ? ?call > >? ? ? >? ? ? >? ? ? > verifier as we go. > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ?Thanks, > >? ? ? >? ? ? >? ? ? >? ? ?David > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? >? ? ? > Jc > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? > Let me know what you all think. When > talking about it a > >? ? ? >? ? ?bit, I had > >? ? ? >? ? ? >? ? ? > gotten some interest to see what it > would look > >? ? ?like. Here > >? ? ? >? ? ?it is > >? ? ? >? ? ? >? ? ?:-). Now > >? ? ? >? ? ? >? ? ? > if it is not wanted like I said, I can > backtrack > >? ? ?and just > >? ? ? >? ? ?put the > >? ? ? >? ? ? >? ? ?error > >? ? ? >? ? ? >? ? ? > checks after each JNI call for all the > tests as we are > >? ? ? >? ? ?porting them. > >? ? ? >? ? ? >? ? ? > Jc > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > -- > >? ? ? >? ? ? > > >? ? ? >? ? ? > Thanks, > >? ? ? >? ? ? > Jc > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > -- > >? ? ? > > >? ? ? > Thanks, > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc > > > > -- > > Thanks, > Jc From david.holmes at oracle.com Thu Sep 27 14:13:10 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 10:13:10 -0400 Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: <8ccc1a0e-d253-4fbd-9d0b-d334cd8b7bb1@default> References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <8f78ff9f-a548-5d5f-bdb0-f366877d2226@oracle.com> <8ccc1a0e-d253-4fbd-9d0b-d334cd8b7bb1@default> Message-ID: LGTM. Thanks, David On 27/09/2018 1:16 AM, Sharath Ballal wrote: > Can I get one more review from a (R)eviewer please ? > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Wednesday, September 26, 2018 9:57 AM > To: Jini Susan George; serviceability-dev > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file > > Thanks for the review Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Wednesday, September 26, 2018 9:42 AM > To: Sharath Ballal; serviceability-dev > Subject: Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file > > Looks good to me. > > Thanks, > Jini. > > On 9/24/2018 9:19 AM, Sharath Ballal wrote: >> Hi, >> >> Pls review this test fix to add "-Xmx512m" to SA tests which create >> either core file or heap dump, to avoid timeout due to large heap sizes. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ >> >> >> SA tests passed on Mach5 run. >> >> Thanks, >> >> Sharath >> From jcbeyler at google.com Thu Sep 27 17:45:31 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 27 Sep 2018 10:45:31 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> Message-ID: Hi Mikael and David, @David: I thought it was implicit but did not want to presume on this one because my goal is to start propagating this new class in the test base and get the checks to be done implicitly so I was probably being over-cautious @Mikael: done and done, what do you think of the comment here : http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html For all, the new webrev is here: Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 Thanks, Jc On Thu, Sep 27, 2018 at 6:03 AM David Holmes wrote: > Sorry Jc, I thought my LGTM was implicit. :) > > Thanks, > David > > On 26/09/2018 11:52 PM, JC Beyler wrote: > > Ping on this, anybody have time to do a review and give a LGTM? Or David > > if you have time and will to provide an explicit LGTM :) > > > > Thanks, > > Jc > > > > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > > wrote: > > > > Hi David, > > > > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting > > for an explicit LGTM from you or from someone else on this list to > > do a review. > > > > Thanks again for your help, > > Jc > > > > On Sun, Sep 23, 2018 at 9:22 AM David Holmes > > > wrote: > > > > Hi Jc, > > > > I don't think it is an issue for this to go ahead. If the static > > analysis tool has an issue then we can either find out how to > > teach it > > about this code structure, or else flag the issues as false > > positives. > > I'd be relying on one of the serviceability team here to handle > > that if > > the problem arises. > > > > Thanks, > > David > > > > On 23/09/2018 12:17 PM, JC Beyler wrote: > > > Hi David, > > > > > > No worries with the time to answer; I appreciate the review! > > > > > > That's a fair point. Is it possible to "describe" to the > > static analysis > > > tool to "trust" calls made in the SafeJNIEnv class? > > > > > > Otherwise, do you have any idea on how to go forward? For > > what it's > > > worth, this current webrev does not try to replace exception > > checking > > > with the SafeJNIEnv (it actually adds it), so for now the > > > question/solution could be delayed. I could continue working > > on this in > > > the scope of both the nsk/gc/lock/jniref code base and the > > NSK_VERIFIER > > > macro removal and we can look at how to tackle the cases > > where the tests > > > are actually calling exception checking (I know my > > heapmonitor does for > > > example). > > > > > > Let me know what you think and thanks for the review, > > > Jc > > > > > > > > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > > > > > > >> wrote: > > > > > > Hi Jc, > > > > > > Sorry for the delay on getting back to this but I'm > > travelling at the > > > moment. > > > > > > This looks quite neat. Thanks also to Alex for all the > > suggestions. > > > > > > My only remaining concern is that static analysis tools > > may not like > > > this because they may not be able to determine that we > > won't make > > > subsequent JNI calls when an exception happens in the > > first. That's not > > > a reason not to do this of course, just flagging that we > > may have to do > > > something to deal with that problem. > > > > > > Thanks, > > > David > > > > > > On 20/09/2018 11:56 AM, JC Beyler wrote: > > > > Hi Alex, > > > > > > > > Done here, thanks for the review: > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > Thanks again! > > > > Jc > > > > > > > > > > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > > > > > > alexey.menkov at oracle.com>> > > > > > > > > > >>> wrote: > > > > > > > > Hi Jc, > > > > > > > > Looks good to me. > > > > A minor note: > > > > - I'd move ErrorHandler typedef to SafeJNIEnv > > class to avoid > > > global > > > > namespece pollution (ErrorHandler is too generic > > name). > > > > > > > > --alex > > > > > > > > On 09/19/2018 15:56, JC Beyler wrote: > > > > > Hi Alex, > > > > > > > > > > I've updated the webrev to: > > > > > Webrev: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> > > > > > > > > > > > > > > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > That webrev has the code that is shown here in > > snippets. > > > > > > > > > > > > > > > Thanks for the reviews, I've relatively > > followed your reviews > > > > except for > > > > > one detail due to me wanting to handle the > > NSK_JNI_VERIFY > > > macros via > > > > > this system as well later down the road. For an > > example: > > > > > > > > > > We currently have in the code: > > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > > NSK_CPP_STUB2(GetObjectClass, > > > > > pEnv, mhToCall)) != NULL) ) > > > > > > > > > > 1) The NSK_CPP_STUB2 is trivially removed with > > a refactor > > > > (JDK-8210728) > > > > > > > to: > > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > > pEnv->GetObjectClass(pEnv, > > > > > mhToCall)) != NULL) ) > > > > > > > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove > > it to and it > > > > becomes via > > > > > this wrapping of JNIEnv: > > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, > > mhToCall)) ) > > > > > > > > > > 3) Then, via removing the assignment, we'd > > arrive to a: > > > > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > > > > if (!mhClass) > > > > > > > > > > Without any loss of checking for failures, etc. > > > > > > > > > > So that is my motivation for most of this work > > with a concrete > > > > example > > > > > (hopefully it helps drive this conversation). > > > > > > > > > > I inlined my answers here, let me know what you > > think. > > > > > > > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > > > > > > alexey.menkov at oracle.com>> > > > > > > alexey.menkov at oracle.com>>> > > > > > > > > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > Hi Jc, > > > > > > > > > > Updated tests looks good. > > > > > Some notes about implementation. > > > > > > > > > > - FatalOnException implements both > > verification and error > > > > handling > > > > > It would be better to separate them (and > > this makes > > > easy to > > > > implement > > > > > error handling different from > > JNIEnv::FatalError). > > > > > The simplest way is to define error handler > as > > > > > class SafeJNIEnv { > > > > > public: > > > > > typedef void (*ErrorHandler)(JNIEnv > > *env, const > > > char* > > > > errorMsg); > > > > > // error handler which terminates jvm > > by using > > > FatalError() > > > > > static void FatalError(JNIEnv *env, > > const char > > > *errrorMsg); > > > > > > > > > > SafeJNIEnv(JNIEnv* jni_env, > ErrorHandler > > > errorHandler = > > > > > FatalError); > > > > > (SafeJNIEnv methods should create > > FatalOnException objects > > > > passing > > > > > errorHandler) > > > > > > > > > > > > > > > > > > > > Agreed, I tried to keep the code simple. The > > concepts you > > > talk about > > > > > here are generally what I reserve for when I > > need it (ie > > > > extensions and > > > > > handling new cases). But a lot are going to be > > needed soon > > > so I > > > > think it > > > > > is a good time to iron the code out now on this > > "simple" > > > webrev. > > > > > > > > > > So done for this. > > > > > > > > > > > > > > > > > > > > - FatalOnException is used in SafeJNIEnv > > methods as > > > > > FatalOnException marker(this, "msg"); > > > > > ret = > > > > > (optional)marker.check_for_null(ret); > > > > > return ret; > > > > > But actually I'd call it something like > > > JNICallResultVerifier and > > > > > create > > > > > the object after JNI call. like > > > > > ret = > > > > > JNICallResultVerifier(this, "msg") > > > > > (optional).notNull(ret); > > > > > return ret; > > > > > or even (if you like such syntax sugar) you > > can define > > > > > template > > > > > T resultNotNull(T result) { > > > > > notNull(result); > > > > > return result; > > > > > } > > > > > and do > > > > > ret = > > > > > return JNICallResultVerifier(this, > > > "msg").resultNotNull(ret); > > > > > > > > > > > > > > > So I renamed FatalOnException to now being > > JNIVerifier. > > > > > > > > > > Though I like it, I don't think we can do it, > > except if we > > > do it > > > > > slightly differently: > > > > > I'm trying to solve two problems with one stone: > > > > > - How to check for returns of JNI calls in > > the way that is > > > > done here > > > > > - How to remove NSK_JNI_VERIFY* (from > > > nsk/share/jni/jni_tools) > > > > > > > > > > However, the NSK_JNI_VERIFY need to start a > > tracing system > > > before > > > > the > > > > > call to JNI, so it won't work this way. (Side > > question > > > would be > > > > do we > > > > > still care about the tracing in NSK_JNI_VERIFY, > > if we > > > don't then > > > > your > > > > > solution works well in most situations). > > > > > > > > > > My vision or intuition is that we would throw a > > template > > > at some > > > > point > > > > > on SafeJNIEnv to handle both cases and have > > JNIVerifier > > > become a > > > > > specialization in certain cases and something > > different > > > for the > > > > > NSK_JNI_VERIFY case (or have a different > > constructor to enable > > > > tracing). > > > > > But for now, I offer the implementation that > does: > > > > > > > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > > > > > JNIVerifier marker(this, > > "GetObjectClass"); > > > > > return > > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > > > > } > > > > > > > > > > and: > > > > > > > > > > void SafeJNIEnv::SetObjectField(jobject obj, > > jfieldID > > > field, jobject > > > > > value) { > > > > > JNIVerifier<> marker(this, "SetObjectField"); > > > > > _jni_env->SetObjectField(obj, field, value); > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > - you added #include in the test > > (and you have to > > > > add it to > > > > > every test). > > > > > It would be simpler to add the include to > > > SafeJNIEnv.hpp and > > > > define > > > > > typedef std::unique_ptr > > SafeJNIEnvPtr; > > > > > Then each in the test methods: > > > > > SafeJNIEnvPtr env(new > SafeJNIEnv(jni_env)); > > > > > or you can add > > > > > static SafeJNIEnv::SafeJNIEnvPtr > > wrap(JNIEnv* jni_env, > > > > ErrorHandler > > > > > errorHandler = fatalError) > > > > > and get > > > > > SafeJNIEnvPtr env = > > SafeJNIEnv::wrap(jni_env); > > > > > > > > > > > > > > > Done, I like that, even less code change to > > tests then. > > > > > > > > > > > > > > > > > > > > - it would be better to wrap internal > classes > > > > (FatalOnException) into > > > > > unnamed namespace - this helps to avoid > > conflicts with > > > other > > > > classes) > > > > > > > > > > - FatalOnException::check_for_null(void* > ptr) > > > > > should be > > > > > FatalOnException::check_for_null(const > > void* ptr) > > > > > And calling the method you don't need > > reinterpret_cast > > > > > > > > > > > > > > > Also done, it got renamed to ResultNotNull, is > > using a > > > template > > > > now, but > > > > > agreed, that worked. > > > > > Thanks again for the review, > > > > > Jc > > > > > > > > > > > > > > > --alex > > > > > > > > > > > > > > > On 09/18/2018 11:07, JC Beyler wrote: > > > > > > Hi David, > > > > > > > > > > > > Thanks for the quick review and > > thoughts. I have > > > now a new > > > > > version here > > > > > > that addresses your comments: > > > > > > > > > > > > Webrev: > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > > > > > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > > > I've also inlined my answers/comments. > > > > > > > > > > > > > > > > > > > > > > > > > I've slowly started working on > > JDK-8191519 > > > > > > > > > > . > > > > > However before > > > > > > > starting to really refactor all > > the tests, I > > > > thought I'd > > > > > get a few > > > > > > > opinions. I am working on > > internalizing the > > > error > > > > handling > > > > > of JNI > > > > > > calls > > > > > > > via a SafeJNIEnv class that > > redefines all > > > the JNI > > > > calls to > > > > > add an > > > > > > error > > > > > > > checker. > > > > > > > > > > > > > > The advantage is that the test > > code will > > > look and > > > > feel like > > > > > > normal JNI > > > > > > > code and calls but will have the > > checks we > > > want to have > > > > > for our > > > > > > tests. > > > > > > > > > > > > Not sure I get that. Normal JNI code > > has to > > > check for > > > > > errors/exceptions > > > > > > after every call. The tests need > > those checks too. > > > > Today they are > > > > > > explicit, with this change they > become > > > implicit. Not sure > > > > > what we are > > > > > > gaining here ?? > > > > > > > > > > > > > > > > > > In my humble opinion, having the error > > checking out > > > of the way > > > > > allows > > > > > > the code reader to concentrate on the > > JNI code while > > > > maintaining > > > > > error > > > > > > checking. We use something similar > > internally, so > > > perhaps I'm > > > > > biased to > > > > > > it :-). > > > > > > If this is not a desired/helpful > > "feature" to simplify > > > > tests in > > > > > general, > > > > > > I will backtrack it and just add the > > explicit tests > > > to the > > > > native > > > > > code > > > > > > of the locks for the fix > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > > > > > > > > > Let me however try to make my case and > > let me know what > > > > you all > > > > > think! > > > > > > > > > > > > > > > > > > > If agreed with this, we can > > augment the > > > SafeJNIEnv > > > > class > > > > > as needed. > > > > > > > Also, if the tests require > > something else > > > than fatal > > > > > errors, we > > > > > > can add > > > > > > > a different marker and make it a > > parameter > > > to the > > > > base class. > > > > > > > > > > > > > > Webrev: > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.00/> > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.00/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > > > > > Let me know what you think, > > > > > > > > > > > > Two initial suggestions: > > > > > > > > > > > > 1. FatalOnException should be > > constructed with a > > > > description > > > > > string so > > > > > > that it can report the failing > > operation when > > > calling > > > > > FatalError rather > > > > > > than the general "Problem with a JNI > > call". > > > > > > > > > > > > > > > > > > Agreed with you, the new webrev produces: > > > > > > > > > > > > FATAL ERROR in native method: > GetObjectClass > > > > > > at > > > > > > > > > > > > > > > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > > > > > at > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > > Method) > > > > > > at > > > > > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > at > > > > > > > > > > > > > > > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > > > > > at > > > > > > > > java.lang.Thread.run(java.base at 12-internal > /Thread.java:834) > > > > > > > > > > > > > > > > > > and for a return NULL in NewGlobalRef, > > we would get > > > > automatically: > > > > > > > > > > > > FATAL ERROR in native method: > > NewGlobalRef:Return > > > is NULL > > > > > > at > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > > Method) > > > > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again as we port and simplify more tests > > (I'll only > > > do the > > > > locks > > > > > for now > > > > > > and we can figure out the next steps as > > start > > > working on > > > > moving > > > > > tests > > > > > > out of vmTestbase), > > > > > > we can add, if needed, other exception > > handlers > > > that don't > > > > throw > > > > > or do > > > > > > other things depending on the JNI method > > outputs. > > > > > > > > > > > > > > > > > > 2. Make the local SafeJNIEnv a > > pointer called > > > env so > > > > that the > > > > > change is > > > > > > less disruptive. All the env->op() > > calls will > > > remain > > > > and only > > > > > the local > > > > > > error checking will be removed. > > > > > > > > > > > > > > > > > > Done, I used a unique_ptr to make the > object > > > > > created/destroyed/available > > > > > > as a pointer do-able in one line: > > > > > > std::unique_ptr env(new > > > SafeJNIEnv(jni_env)); > > > > > > > > > > > > and then you can see that, as you > > mentioned, the > > > disruption to > > > > > the code > > > > > > is much less: > > > > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > Basically the tests now become internal > > to the > > > SafeJNIEnv > > > > and the > > > > > code > > > > > > now only contains the JNI calls > > happening but we > > > are protected > > > > > and will > > > > > > fail any test that has an exception or a > > NULL > > > return for the > > > > > call. Of > > > > > > course, this is not 100% proof in terms > > of not > > > having any > > > > error > > > > > handling > > > > > > in the test but in some cases like this, > > the new > > > code seems to > > > > > just work > > > > > > better: > > > > > > > > > > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > > > > > > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > > > > > > > > > The switch from, e.g., checking NULL > > returns to > > > > checking for > > > > > pending > > > > > > exceptions, need to be sure that the > > JNI operations > > > > clearly > > > > > specify > > > > > > that > > > > > > NULL implies there will be an > exception > > > pending. This > > > > change > > > > > may be an > > > > > > issue for static code analysis if > > not smart > > > enough to > > > > > understand the > > > > > > RAII wrappers. > > > > > > > > > > > > > > > > > > Agreed, I fixed it to be more strict and > > say: in > > > normal test > > > > > handling, > > > > > > the JNI calls should never return NULL > > or throw an > > > > exception. This > > > > > > should hold for tests I imagine but if > > not we can add a > > > > different > > > > > call > > > > > > verifier as we go. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > David > > > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > > > > > Let me know what you all think. When > > talking about it a > > > > bit, I had > > > > > > gotten some interest to see what it > > would look > > > like. Here > > > > it is > > > > > :-). Now > > > > > > if it is not wanted like I said, I can > > backtrack > > > and just > > > > put the > > > > > error > > > > > > checks after each JNI call for all the > > tests as we are > > > > porting them. > > > > > > Jc > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Thanks, > > > > > Jc > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Thu Sep 27 18:00:05 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 27 Sep 2018 11:00:05 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> Message-ID: <3ED2E5D2-2215-4DE8-B368-3C4B9BDA48F8@oracle.com> Hi Serguei, Thank you for reviewing this change. Initially I understood the whole fragment below? (from the Javadoc for com.sun.jdi.connect.ListeningConnector.startListening() method) as a direction for the user how to obtain and prepare the argument map before passing it in startListening() method. ? 61????? * The argument map associates argument name strings to instances ? 62????? * of {@link Connector.Argument}. The default argument map for a ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. ? 64????? * Argument map values can be changed, but map entries should not be ? 65????? * added or deleted. But I agree that the last sentence could also mean that the argument map values could be changes as a result of the method invocation and in this case the new fragment in the Javadoc is not needed. Please review the updated webrev that does not add new Javadoc fragment and includes other changes you suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.07/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: Organization: Oracle Corporation Date: Wednesday, September 26, 2018 at 8:12 PM To: Daniil Titov , JC Beyler Cc: , , Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Hi Daniil, It is great that you came up the fix for this issue. Thanks to Gary for the help too. I wonder if we could get away without updating the javadoc of com/sun/jdi/connect/ListeningConnector.java. Filing a CSR would not be needed then (simple javadoc reformatting should not require a CSR). So, my question is if this new fragment is really needed: ? 76????? *

? 77????? * If the addressing information provided in {@code arguments} implies ? 78????? * the auto detection this information might be updated with the address ? 79????? * of the started listener. The javadoc for startListening already has this fragment: ? 61????? * The argument map associates argument name strings to instances ? 62????? * of {@link Connector.Argument}. The default argument map for a ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. ? 64????? * Argument map values can be changed, but map entries should not be ? 65????? * added or deleted. that allows to change the argument map values. It looks like, it has to be Okay to add the bound port number there. Please, let me know what you think. Some formatting comments to addition to Jc's comments: ? 77????? * If the addressing information provided in {@code arguments} implies ? 78????? * the auto detection this information might be updated with the address ? 79????? * of the started listener. This sentence needs to be split in two: ? 77????? * If the addressing information provided in {@code arguments} implies ? 78????? * the auto detection. This information might be updated with the address ? 79????? * of the started listener. + +??? protected void updateArgumentMapIfRequired( +??????????? Map args,TransportService.ListenKey listener) { +??? } + ? The indent has to be 4, not 8. +??????? if(isWildcardPort(args)) { +??????????? String[] address = listener.address().split(":"); +??????????? if (address.length > 1) { +??????????????? args.get(ARG_PORT).setValue(address[1]); +??????????? } +??????? } ? A space is missed after the first 'if'. ? 50???????????????????????? filter(c -> ? 51????????????? ???????????????????c.name().equals("com.sun.jdi.SocketListen")).findFirst().get(); This is better to be one liner. ? 57???????? testWithDefaultArgs(connector); ? 58???????? testWithDefaultArgs2(connector); ? 59???????? testWithWildcardPort(connector); ? 60???????? testWithWildcardPort2(connector); ? A suggestion is to rename above as below to have the names more unified: ? 57???????? testWithDefaultArgs1(connector); ? 58???????? testWithDefaultArgs2(connector); ? 59???????? testWithWildcardPort1(connector); ? 60???????? testWithWildcardPort2(connector); Thanks, Serguei On 9/25/18 10:32 AM, Daniil Titov wrote: HI JC, The webrev is updated to address this. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: JC Beyler Date: Monday, September 24, 2018 at 8:47 PM To: Cc: , , Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Hi Daniil, Still looks good to me :) Nit: empty line 83 of the new test is not required! Jc On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov wrote: Hi Alex, Please review the updated webrev that has new test moved to test/jdk/comsun/jdi/connect folder. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil ?On 9/24/18, 2:56 PM, "Alex Menkov" wrote: Daniil, Just remembered that SQE requested to not add new tests to vmTestbase (see test/hotspot/jtreg/vmTestbase/README.md) Could you please move the test to correct location (I suppose it's test/jdk/com/sun/jdi) --alex On 09/24/2018 14:30, Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 10:39, Gary Adams wrote: >> Looks good to me. >> >> On 9/24/18, 1:25 PM, Daniil Titov wrote: >>> Hi Alex and Gary, >>> >>> Please review the updated patch that includes suggested changes. >>> >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >>> Thanks! >>> --Daniil >>> >>> >>> >>> >>> ?On 9/21/18, 3:59 PM, "Alex Menkov" wrote: >>> >>> One more note: >>> please add "@Override" annotation to the >>> SocketListeningConnector.updateArgumentMapIfRequired >>> >>> --alex >>> >>> On 09/21/2018 02:26, gary.adams at oracle.com wrote: >>> > Looks good to me. >>> > >>> > For the javadoc >>> > >>> > 72 *

>>> > 73 * Ifarguments contains addressing >>> information. and >>> > 74 * only one connection will be accepted, the {@link >>> #accept accept} method >>> > 75 * can be called immediately without calling this >>> method. >>> > 76 * >>> > 77 * If the addressing information provided >>> inarguments >>> > implies >>> > 78 * the auto detection this information might be updated >>> with the address >>> > 79 * of the started listener. >>> > >>> > - you could add a

tag if you want to maintain the >>> spacing in the >>> > generated javadoc. >>> > - I've seen other changesets migrating to {@code ..} from >>> the older >>> > ... >>> > >>> > It would be good to include some negative testing. >>> > Not sure if it is already covered in other tests, e.g. >>> > >>> > args1 = defaultArguments() >>> > startListening(args1) // bound port updated >>> > startListening(args1) // already listening >>> > >>> > >>> > On 9/20/18 10:59 PM, Daniil Titov wrote: >>> >> Please review the change that fixes the issue in >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. >>> >> >>> >> When the argument map passed to startListening() methods has >>> the port number unspecified or set to zero the port is auto detected. >>> However, the consequent call of startListening() methods with >>> unspecified port number fails rather than starts a new listener on >>> auto detected port. This happens since the original argument map >>> passed to the startListening() methods is used as a key to store the >>> mapping to the started listeners. >>> >> >>> >> The fix ensures that in cases when the port is auto detected >>> the argument map is updated with the bound port number. >>> >> >>> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. >>> >> >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> > >>> >>> >>> >> -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Sep 27 18:19:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 14:19:48 -0400 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> Message-ID: <577e8f3f-1835-c1b2-2b6f-8f82cccfe1c6@oracle.com> Hi Jc, This seems fine to me. I'll leave it to you and Mikael to wrestle out the naming. Thanks, David On 27/09/2018 1:45 PM, JC Beyler wrote: > Hi Mikael and David, > > @David: I thought it was implicit but did not want to presume on this > one because my goal is to start propagating this new class in the test > base and get the checks to be done implicitly so I was probably being > over-cautious > @Mikael: done and done, what do you think of the comment here : > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html > > > For all, the new webrev is here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > Thanks, > Jc > > On Thu, Sep 27, 2018 at 6:03 AM David Holmes > wrote: > > Sorry Jc, I thought my LGTM was implicit. :) > > Thanks, > David > > On 26/09/2018 11:52 PM, JC Beyler wrote: > > Ping on this, anybody have time to do a review and give a LGTM? > Or David > > if you have time and will to provide an explicit LGTM :) > > > > Thanks, > > Jc > > > > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > > >> wrote: > > > >? ? ?Hi David, > > > >? ? ?Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting > >? ? ?for an explicit LGTM from you or from someone else on this > list to > >? ? ?do a review. > > > >? ? ?Thanks again for your help, > >? ? ?Jc > > > >? ? ?On Sun, Sep 23, 2018 at 9:22 AM David Holmes > >? ? ? > >> > wrote: > > > >? ? ? ? ?Hi Jc, > > > >? ? ? ? ?I don't think it is an issue for this to go ahead. If the > static > >? ? ? ? ?analysis tool has an issue then we can either find out how to > >? ? ? ? ?teach it > >? ? ? ? ?about this code structure, or else flag the issues as false > >? ? ? ? ?positives. > >? ? ? ? ?I'd be relying on one of the serviceability team here to > handle > >? ? ? ? ?that if > >? ? ? ? ?the problem arises. > > > >? ? ? ? ?Thanks, > >? ? ? ? ?David > > > >? ? ? ? ?On 23/09/2018 12:17 PM, JC Beyler wrote: > >? ? ? ? ? > Hi David, > >? ? ? ? ? > > >? ? ? ? ? > No worries with the time to answer; I appreciate the > review! > >? ? ? ? ? > > >? ? ? ? ? > That's a fair point. Is it possible to "describe" to the > >? ? ? ? ?static analysis > >? ? ? ? ? > tool to "trust" calls made in the SafeJNIEnv class? > >? ? ? ? ? > > >? ? ? ? ? > Otherwise, do you have any idea on how to go forward? For > >? ? ? ? ?what it's > >? ? ? ? ? > worth, this current webrev does not try to replace > exception > >? ? ? ? ?checking > >? ? ? ? ? > with the SafeJNIEnv (it actually adds it), so for now the > >? ? ? ? ? > question/solution could be delayed. I could continue > working > >? ? ? ? ?on this in > >? ? ? ? ? > the scope of both the nsk/gc/lock/jniref code base and the > >? ? ? ? ?NSK_VERIFIER > >? ? ? ? ? > macro removal and we can look at how to tackle the cases > >? ? ? ? ?where the tests > >? ? ? ? ? > are actually calling exception checking (I know my > >? ? ? ? ?heapmonitor does for > >? ? ? ? ? > example). > >? ? ? ? ? > > >? ? ? ? ? > Let me know what you think and thanks for the review, > >? ? ? ? ? > Jc > >? ? ? ? ? > > >? ? ? ? ? > > >? ? ? ? ? > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > >? ? ? ? ? > > > >? ? ? ? ? > > >? ? ? ? ? >>> wrote: > >? ? ? ? ? > > >? ? ? ? ? >? ? ?Hi Jc, > >? ? ? ? ? > > >? ? ? ? ? >? ? ?Sorry for the delay on getting back to this but I'm > >? ? ? ? ?travelling at the > >? ? ? ? ? >? ? ?moment. > >? ? ? ? ? > > >? ? ? ? ? >? ? ?This looks quite neat. Thanks also to Alex for all the > >? ? ? ? ?suggestions. > >? ? ? ? ? > > >? ? ? ? ? >? ? ?My only remaining concern is that static analysis > tools > >? ? ? ? ?may not like > >? ? ? ? ? >? ? ?this because they may not be able to determine that we > >? ? ? ? ?won't make > >? ? ? ? ? >? ? ?subsequent JNI calls when an exception happens in the > >? ? ? ? ?first. That's not > >? ? ? ? ? >? ? ?a reason not to do this of course, just flagging > that we > >? ? ? ? ?may have to do > >? ? ? ? ? >? ? ?something to deal with that problem. > >? ? ? ? ? > > >? ? ? ? ? >? ? ?Thanks, > >? ? ? ? ? >? ? ?David > >? ? ? ? ? > > >? ? ? ? ? >? ? ?On 20/09/2018 11:56 AM, JC Beyler wrote: > >? ? ? ? ? >? ? ? > Hi Alex, > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > Done here, thanks for the review: > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > >? ? ? ? ? > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > >? ? ? ? ? >? ? ? > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > Thanks again! > >? ? ? ? ? >? ? ? > Jc > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > >? ? ? ? ? >? ? ? > >? ? ? ? ? > > >? ? ? ? ? >> > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > >? ? ? ? ? >? ? ? > >? ? ? ? ? >>>> wrote: > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ?Hi Jc, > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ?Looks good to me. > >? ? ? ? ? >? ? ? >? ? ?A minor note: > >? ? ? ? ? >? ? ? >? ? ?- I'd move ErrorHandler typedef to SafeJNIEnv > >? ? ? ? ?class to avoid > >? ? ? ? ? >? ? ?global > >? ? ? ? ? >? ? ? >? ? ?namespece pollution (ErrorHandler is too > generic > >? ? ? ? ?name). > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ?--alex > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ?On 09/19/2018 15:56, JC Beyler wrote: > >? ? ? ? ? >? ? ? >? ? ? > Hi Alex, > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > I've updated the webrev to: > >? ? ? ? ? >? ? ? >? ? ? > Webrev: > >? ? ? ? ? > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > >? ? ? ? ? > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? > > >? ? ? ? ? ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > >? ? ? ? ? >? ? ? >? ? ? > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > That webrev has the code that is shown > here in > >? ? ? ? ?snippets. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Thanks for the reviews, I've relatively > >? ? ? ? ?followed your reviews > >? ? ? ? ? >? ? ? >? ? ?except for > >? ? ? ? ? >? ? ? >? ? ? > one detail due to me wanting to handle the > >? ? ? ? ?NSK_JNI_VERIFY > >? ? ? ? ? >? ? ?macros via > >? ? ? ? ? >? ? ? >? ? ? > this system as well later down the road. > For an > >? ? ? ? ?example: > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > We currently have in the code: > >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > >? ? ? ? ? >? ? ?NSK_CPP_STUB2(GetObjectClass, > >? ? ? ? ? >? ? ? >? ? ? > pEnv, mhToCall)) != NULL) ) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > 1) The NSK_CPP_STUB2 is trivially > removed with > >? ? ? ? ?a refactor > >? ? ? ? ? >? ? ? >? ? ?(JDK-8210728) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ??to: > >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > >? ? ? ? ? >? ? ?pEnv->GetObjectClass(pEnv, > >? ? ? ? ? >? ? ? >? ? ? > mhToCall)) != NULL) ) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > 2) Then the NSK_JNI_VERIFY, I'd like to > remove > >? ? ? ? ?it to and it > >? ? ? ? ? >? ? ? >? ? ?becomes via > >? ? ? ? ? >? ? ? >? ? ? > this wrapping of JNIEnv: > >? ? ? ? ? >? ? ? >? ? ? > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, > >? ? ? ? ?mhToCall)) ) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > 3) Then, via removing the assignment, we'd > >? ? ? ? ?arrive to a: > >? ? ? ? ? >? ? ? >? ? ? > mhClass = pEnv->GetObjectClass(pEnv, > mhToCall)); > >? ? ? ? ? >? ? ? >? ? ? > if (!mhClass) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Without any loss of checking for > failures, etc. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > So that is my motivation for most of > this work > >? ? ? ? ?with a concrete > >? ? ? ? ? >? ? ? >? ? ?example > >? ? ? ? ? >? ? ? >? ? ? > (hopefully it helps drive this > conversation). > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > I inlined my answers here, let me > know?what you > >? ? ? ? ?think. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > >? ? ? ? ? >? ? ? >? ? ? > >? ? ? ? ? > > >? ? ? ? ? >> > >? ? ? ? ? >? ? ? > >? ? ? ? ? > > >? ? ? ? ? >>> > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > >? ? ? ? ? >? ? ? > >? ? ? ? ? >> > >? ? ? ? ? >? ? ? >? ? ? > >? ? ? ? ? > > >? ? ? ? ? >? ? ? > >? ? ? ? ? >>>>> wrote: > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?Hi Jc, > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?Updated tests looks good. > >? ? ? ? ? >? ? ? >? ? ? >? ? ?Some notes about implementation. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- FatalOnException implements both > >? ? ? ? ?verification and error > >? ? ? ? ? >? ? ? >? ? ?handling > >? ? ? ? ? >? ? ? >? ? ? >? ? ?It would be better to separate them (and > >? ? ? ? ?this makes > >? ? ? ? ? >? ? ?easy to > >? ? ? ? ? >? ? ? >? ? ?implement > >? ? ? ? ? >? ? ? >? ? ? >? ? ?error handling different from > >? ? ? ? ?JNIEnv::FatalError). > >? ? ? ? ? >? ? ? >? ? ? >? ? ?The simplest way is to define error > handler as > >? ? ? ? ? >? ? ? >? ? ? >? ? ?class SafeJNIEnv { > >? ? ? ? ? >? ? ? >? ? ? >? ? ?public: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ?typedef void > (*ErrorHandler)(JNIEnv > >? ? ? ? ?*env, const > >? ? ? ? ? >? ? ?char* > >? ? ? ? ? >? ? ? >? ? ?errorMsg); > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ?// error handler which > terminates jvm > >? ? ? ? ?by using > >? ? ? ? ? >? ? ?FatalError() > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ?static void FatalError(JNIEnv > *env, > >? ? ? ? ?const char > >? ? ? ? ? >? ? ?*errrorMsg); > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ?SafeJNIEnv(JNIEnv* jni_env, > ErrorHandler > >? ? ? ? ? >? ? ?errorHandler = > >? ? ? ? ? >? ? ? >? ? ? >? ? ?FatalError); > >? ? ? ? ? >? ? ? >? ? ? >? ? ?(SafeJNIEnv methods should create > >? ? ? ? ?FatalOnException objects > >? ? ? ? ? >? ? ? >? ? ?passing > >? ? ? ? ? >? ? ? >? ? ? >? ? ?errorHandler) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Agreed, I tried to keep the code simple. The > >? ? ? ? ?concepts you > >? ? ? ? ? >? ? ?talk about > >? ? ? ? ? >? ? ? >? ? ? > here are generally what I reserve for when I > >? ? ? ? ?need it (ie > >? ? ? ? ? >? ? ? >? ? ?extensions and > >? ? ? ? ? >? ? ? >? ? ? > handling new cases). But a lot are going > to be > >? ? ? ? ?needed soon > >? ? ? ? ? >? ? ?so I > >? ? ? ? ? >? ? ? >? ? ?think it > >? ? ? ? ? >? ? ? >? ? ? > is a good time to iron the code out now > on this > >? ? ? ? ?"simple" > >? ? ? ? ? >? ? ?webrev. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > So done for this. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- FatalOnException is used in SafeJNIEnv > >? ? ? ? ?methods as > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?FatalOnException marker(this, > "msg"); > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?ret = > >? ? ? ? ? >? ? ? >? ? ? > > ?(optional)marker.check_for_null(ret); > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?return ret; > >? ? ? ? ? >? ? ? >? ? ? >? ? ?But actually I'd call it something like > >? ? ? ? ? >? ? ?JNICallResultVerifier and > >? ? ? ? ? >? ? ? >? ? ? >? ? ?create > >? ? ? ? ? >? ? ? >? ? ? >? ? ?the object after JNI call. like > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?ret = > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?JNICallResultVerifier(this, "msg") > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ?(optional).notNull(ret); > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?return ret; > >? ? ? ? ? >? ? ? >? ? ? >? ? ?or even (if you like such syntax > sugar) you > >? ? ? ? ?can define > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?template > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?T resultNotNull(T result) { > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ?notNull(result); > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ? ? ?return result; > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?} > >? ? ? ? ? >? ? ? >? ? ? >? ? ?and do > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?ret = > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?return JNICallResultVerifier(this, > >? ? ? ? ? >? ? ?"msg").resultNotNull(ret); > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > So I renamed FatalOnException to now being > >? ? ? ? ?JNIVerifier. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Though I like it, I don't think we can > do it, > >? ? ? ? ?except if we > >? ? ? ? ? >? ? ?do it > >? ? ? ? ? >? ? ? >? ? ? > slightly differently: > >? ? ? ? ? >? ? ? >? ? ? > I'm trying to solve two problems with > one stone: > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- How to check for returns of JNI > calls in > >? ? ? ? ?the way that is > >? ? ? ? ? >? ? ? >? ? ?done here > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- How to remove NSK_JNI_VERIFY* (from > >? ? ? ? ? >? ? ?nsk/share/jni/jni_tools) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > However, the NSK_JNI_VERIFY need to start a > >? ? ? ? ?tracing system > >? ? ? ? ? >? ? ?before > >? ? ? ? ? >? ? ? >? ? ?the > >? ? ? ? ? >? ? ? >? ? ? > call to JNI, so it won't work this way. > (Side > >? ? ? ? ?question > >? ? ? ? ? >? ? ?would be > >? ? ? ? ? >? ? ? >? ? ?do we > >? ? ? ? ? >? ? ? >? ? ? > still care about the tracing in > NSK_JNI_VERIFY, > >? ? ? ? ?if we > >? ? ? ? ? >? ? ?don't then > >? ? ? ? ? >? ? ? >? ? ?your > >? ? ? ? ? >? ? ? >? ? ? > solution works well in most situations). > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > My vision or intuition is that we would > throw a > >? ? ? ? ?template > >? ? ? ? ? >? ? ?at some > >? ? ? ? ? >? ? ? >? ? ?point > >? ? ? ? ? >? ? ? >? ? ? > on SafeJNIEnv to handle both cases and have > >? ? ? ? ?JNIVerifier > >? ? ? ? ? >? ? ?become a > >? ? ? ? ? >? ? ? >? ? ? > specialization in certain cases and > something > >? ? ? ? ?different > >? ? ? ? ? >? ? ?for the > >? ? ? ? ? >? ? ? >? ? ? > NSK_JNI_VERIFY case (or have a different > >? ? ? ? ?constructor to enable > >? ? ? ? ? >? ? ? >? ? ?tracing). > >? ? ? ? ? >? ? ? >? ? ? > But for now, I offer the implementation > that does: > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > jclass > SafeJNIEnv::GetObjectClass(jobject obj) { > >? ? ? ? ? >? ? ? >? ? ? >? ? JNIVerifier marker(this, > >? ? ? ? ?"GetObjectClass"); > >? ? ? ? ? >? ? ? >? ? ? >? ? return > >? ? ? ? ?marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > >? ? ? ? ? >? ? ? >? ? ? > } > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > and: > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > void SafeJNIEnv::SetObjectField(jobject obj, > >? ? ? ? ?jfieldID > >? ? ? ? ? >? ? ?field, jobject > >? ? ? ? ? >? ? ? >? ? ? > value) { > >? ? ? ? ? >? ? ? >? ? ? >? ? JNIVerifier<> marker(this, > "SetObjectField"); > >? ? ? ? ? >? ? ? >? ? ? >? ? _jni_env->SetObjectField(obj, field, > value); > >? ? ? ? ? >? ? ? >? ? ? > } > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- you added #include in the > test > >? ? ? ? ?(and you have to > >? ? ? ? ? >? ? ? >? ? ?add it to > >? ? ? ? ? >? ? ? >? ? ? >? ? ?every test). > >? ? ? ? ? >? ? ? >? ? ? >? ? ?It would be simpler to add the > include to > >? ? ? ? ? >? ? ?SafeJNIEnv.hpp and > >? ? ? ? ? >? ? ? >? ? ?define > >? ? ? ? ? >? ? ? >? ? ? >? ? ?typedef std::unique_ptr > >? ? ? ? ?SafeJNIEnvPtr; > >? ? ? ? ? >? ? ? >? ? ? >? ? ?Then each in the test methods: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?SafeJNIEnvPtr env(new > SafeJNIEnv(jni_env)); > >? ? ? ? ? >? ? ? >? ? ? >? ? ?or you can add > >? ? ? ? ? >? ? ? >? ? ? >? ? ?static SafeJNIEnv::SafeJNIEnvPtr > >? ? ? ? ?wrap(JNIEnv* jni_env, > >? ? ? ? ? >? ? ? >? ? ?ErrorHandler > >? ? ? ? ? >? ? ? >? ? ? >? ? ?errorHandler = fatalError) > >? ? ? ? ? >? ? ? >? ? ? >? ? ?and get > >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?SafeJNIEnvPtr env = > >? ? ? ? ?SafeJNIEnv::wrap(jni_env); > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Done, I like that, even less code change to > >? ? ? ? ?tests then. > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- it would be better to wrap > internal classes > >? ? ? ? ? >? ? ? >? ? ?(FatalOnException) into > >? ? ? ? ? >? ? ? >? ? ? >? ? ?unnamed namespace - this helps to avoid > >? ? ? ? ?conflicts with > >? ? ? ? ? >? ? ?other > >? ? ? ? ? >? ? ? >? ? ?classes) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?- > FatalOnException::check_for_null(void* ptr) > >? ? ? ? ? >? ? ? >? ? ? >? ? ?should be > >? ? ? ? ? >? ? ? >? ? ? >? ? ?FatalOnException::check_for_null(const > >? ? ? ? ?void* ptr) > >? ? ? ? ? >? ? ? >? ? ? >? ? ?And calling the method you don't need > >? ? ? ? ?reinterpret_cast > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Also done, it got renamed to > ResultNotNull, is > >? ? ? ? ?using a > >? ? ? ? ? >? ? ?template > >? ? ? ? ? >? ? ? >? ? ?now, but > >? ? ? ? ? >? ? ? >? ? ? > agreed, that worked. > >? ? ? ? ? >? ? ? >? ? ? > Thanks again for the review, > >? ? ? ? ? >? ? ? >? ? ? > Jc > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?--alex > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ?On 09/18/2018 11:07, JC Beyler wrote: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Hi David, > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Thanks for the quick review and > >? ? ? ? ?thoughts. I have > >? ? ? ? ? >? ? ?now a new > >? ? ? ? ? >? ? ? >? ? ? >? ? ?version here > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > that addresses your comments: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Webrev: > >? ? ? ? ? >? ? ? > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > >? ? ? ? ? > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? > > >? ? ? ? ? ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ?Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > I've also inlined my > answers/comments. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > I've slowly started working on > >? ? ? ? ?JDK-8191519 > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ?. > >? ? ? ? ? >? ? ? >? ? ? >? ? ?However before > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > starting to really > refactor all > >? ? ? ? ?the tests, I > >? ? ? ? ? >? ? ? >? ? ?thought I'd > >? ? ? ? ? >? ? ? >? ? ? >? ? ?get a few > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > opinions.?I am working on > >? ? ? ? ?internalizing the > >? ? ? ? ? >? ? ?error > >? ? ? ? ? >? ? ? >? ? ?handling > >? ? ? ? ? >? ? ? >? ? ? >? ? ?of JNI > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?calls > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > via a SafeJNIEnv class that > >? ? ? ? ?redefines all > >? ? ? ? ? >? ? ?the JNI > >? ? ? ? ? >? ? ? >? ? ?calls to > >? ? ? ? ? >? ? ? >? ? ? >? ? ?add an > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?error > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > checker. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > The advantage is that the test > >? ? ? ? ?code will > >? ? ? ? ? >? ? ?look and > >? ? ? ? ? >? ? ? >? ? ?feel like > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?normal JNI > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > code and calls but will > have the > >? ? ? ? ?checks we > >? ? ? ? ? >? ? ?want to have > >? ? ? ? ? >? ? ? >? ? ? >? ? ?for our > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?tests. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?Not sure I get that. Normal > JNI code > >? ? ? ? ?has to > >? ? ? ? ? >? ? ?check for > >? ? ? ? ? >? ? ? >? ? ? >? ? ?errors/exceptions > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?after every call. The tests need > >? ? ? ? ?those checks too. > >? ? ? ? ? >? ? ? >? ? ?Today they are > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?explicit, with this change > they become > >? ? ? ? ? >? ? ?implicit. Not sure > >? ? ? ? ? >? ? ? >? ? ? >? ? ?what we are > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?gaining here ?? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > In my humble opinion, having the > error > >? ? ? ? ?checking out > >? ? ? ? ? >? ? ?of the way > >? ? ? ? ? >? ? ? >? ? ? >? ? ?allows > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > the code reader to concentrate on the > >? ? ? ? ?JNI code while > >? ? ? ? ? >? ? ? >? ? ?maintaining > >? ? ? ? ? >? ? ? >? ? ? >? ? ?error > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > checking. We use something similar > >? ? ? ? ?internally, so > >? ? ? ? ? >? ? ?perhaps I'm > >? ? ? ? ? >? ? ? >? ? ? >? ? ?biased to > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > it :-). > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > If this is not a desired/helpful > >? ? ? ? ?"feature" to simplify > >? ? ? ? ? >? ? ? >? ? ?tests in > >? ? ? ? ? >? ? ? >? ? ? >? ? ?general, > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > I will backtrack it and just add the > >? ? ? ? ?explicit tests > >? ? ? ? ? >? ? ?to the > >? ? ? ? ? >? ? ? >? ? ?native > >? ? ? ? ? >? ? ? >? ? ? >? ? ?code > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > of the locks for the fix > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > https://bugs.openjdk.java.net/browse/JDK-8191519?instead. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Let me however try to make my > case and > >? ? ? ? ?let me know what > >? ? ? ? ? >? ? ? >? ? ?you all > >? ? ? ? ? >? ? ? >? ? ? >? ? ?think! > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > If agreed with this, we can > >? ? ? ? ?augment the > >? ? ? ? ? >? ? ?SafeJNIEnv > >? ? ? ? ? >? ? ? >? ? ?class > >? ? ? ? ? >? ? ? >? ? ? >? ? ?as needed. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > Also, if the tests require > >? ? ? ? ?something else > >? ? ? ? ? >? ? ?than fatal > >? ? ? ? ? >? ? ? >? ? ? >? ? ?errors, we > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?can add > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > a different marker and > make it a > >? ? ? ? ?parameter > >? ? ? ? ? >? ? ?to the > >? ? ? ? ? >? ? ? >? ? ?base class. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > Webrev: > >? ? ? ? ? >? ? ? >? ? ? > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > >? ? ? ? ? > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? > > >? ? ? ? ? ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > Bug: > >? ? ? ? ? > https://bugs.openjdk.java.net/browse/JDK-8210842 > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > Let me know what you think, > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?Two initial suggestions: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?1. FatalOnException should be > >? ? ? ? ?constructed with a > >? ? ? ? ? >? ? ? >? ? ?description > >? ? ? ? ? >? ? ? >? ? ? >? ? ?string so > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?that it can report the failing > >? ? ? ? ?operation when > >? ? ? ? ? >? ? ?calling > >? ? ? ? ? >? ? ? >? ? ? >? ? ?FatalError rather > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?than the general "Problem > with a JNI > >? ? ? ? ?call". > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Agreed with you, the new webrev > produces: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > FATAL ERROR in native method: > GetObjectClass > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ? ? ? >? ? ? >? ? ? >? ? ?Method) > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > and for a return NULL in > NewGlobalRef, > >? ? ? ? ?we would get > >? ? ? ? ? >? ? ? >? ? ?automatically: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > FATAL ERROR in native method: > >? ? ? ? ?NewGlobalRef:Return > >? ? ? ? ? >? ? ?is NULL > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > >? ? ? ? ? >? ? ? >? ? ? >? ? ?Method) > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? ? ? at > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Again as we port and simplify > more tests > >? ? ? ? ?(I'll only > >? ? ? ? ? >? ? ?do the > >? ? ? ? ? >? ? ? >? ? ?locks > >? ? ? ? ? >? ? ? >? ? ? >? ? ?for now > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > and we can figure out the next > steps as > >? ? ? ? ?start > >? ? ? ? ? >? ? ?working on > >? ? ? ? ? >? ? ? >? ? ?moving > >? ? ? ? ? >? ? ? >? ? ? >? ? ?tests > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > out of vmTestbase), > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > we can add, if needed, other > exception > >? ? ? ? ?handlers > >? ? ? ? ? >? ? ?that don't > >? ? ? ? ? >? ? ? >? ? ?throw > >? ? ? ? ? >? ? ? >? ? ? >? ? ?or do > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > other things depending on the JNI > method > >? ? ? ? ?outputs. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?2. Make the local SafeJNIEnv a > >? ? ? ? ?pointer called > >? ? ? ? ? >? ? ?env so > >? ? ? ? ? >? ? ? >? ? ?that the > >? ? ? ? ? >? ? ? >? ? ? >? ? ?change is > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?less disruptive. All the > env->op() > >? ? ? ? ?calls will > >? ? ? ? ? >? ? ?remain > >? ? ? ? ? >? ? ? >? ? ?and only > >? ? ? ? ? >? ? ? >? ? ? >? ? ?the local > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?error checking will be removed. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Done, I used a unique_ptr to make > the object > >? ? ? ? ? >? ? ? >? ? ? >? ? ?created/destroyed/available > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > as a pointer do-able in one line: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > std::unique_ptr env(new > >? ? ? ? ? >? ? ?SafeJNIEnv(jni_env)); > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > and then you can see that, as you > >? ? ? ? ?mentioned, the > >? ? ? ? ? >? ? ?disruption to > >? ? ? ? ? >? ? ? >? ? ? >? ? ?the code > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > is much less: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > ? > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Basically the tests now become > internal > >? ? ? ? ?to the > >? ? ? ? ? >? ? ?SafeJNIEnv > >? ? ? ? ? >? ? ? >? ? ?and the > >? ? ? ? ? >? ? ? >? ? ? >? ? ?code > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > now only contains the JNI calls > >? ? ? ? ?happening but we > >? ? ? ? ? >? ? ?are protected > >? ? ? ? ? >? ? ? >? ? ? >? ? ?and will > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > fail any test that has an > exception or a > >? ? ? ? ?NULL > >? ? ? ? ? >? ? ?return for the > >? ? ? ? ? >? ? ? >? ? ? >? ? ?call. Of > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > course, this is not 100% proof in > terms > >? ? ? ? ?of not > >? ? ? ? ? >? ? ?having any > >? ? ? ? ? >? ? ? >? ? ?error > >? ? ? ? ? >? ? ? >? ? ? >? ? ?handling > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > in the test but in some cases > like this, > >? ? ? ? ?the new > >? ? ? ? ? >? ? ?code seems to > >? ? ? ? ? >? ? ? >? ? ? >? ? ?just work > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > better: > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > ? > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? > > > > ? > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?The switch from, e.g., > checking NULL > >? ? ? ? ?returns to > >? ? ? ? ? >? ? ? >? ? ?checking for > >? ? ? ? ? >? ? ? >? ? ? >? ? ?pending > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?exceptions, need to be sure > that the > >? ? ? ? ?JNI operations > >? ? ? ? ? >? ? ? >? ? ?clearly > >? ? ? ? ? >? ? ? >? ? ? >? ? ?specify > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?that > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?NULL implies there will be an > exception > >? ? ? ? ? >? ? ?pending. This > >? ? ? ? ? >? ? ? >? ? ?change > >? ? ? ? ? >? ? ? >? ? ? >? ? ?may be an > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?issue for static code analysis if > >? ? ? ? ?not smart > >? ? ? ? ? >? ? ?enough to > >? ? ? ? ? >? ? ? >? ? ? >? ? ?understand the > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?RAII wrappers. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Agreed, I fixed it to be more > strict and > >? ? ? ? ?say: in > >? ? ? ? ? >? ? ?normal test > >? ? ? ? ? >? ? ? >? ? ? >? ? ?handling, > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > the JNI calls should never return > NULL > >? ? ? ? ?or throw an > >? ? ? ? ? >? ? ? >? ? ?exception. This > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > should hold for tests I imagine > but if > >? ? ? ? ?not we can add a > >? ? ? ? ? >? ? ? >? ? ?different > >? ? ? ? ? >? ? ? >? ? ? >? ? ?call > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > verifier as we go. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?Thanks, > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ?David > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? >? ? ? > Jc > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Let me know what you all think. When > >? ? ? ? ?talking about it a > >? ? ? ? ? >? ? ? >? ? ?bit, I had > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > gotten some interest to see what it > >? ? ? ? ?would look > >? ? ? ? ? >? ? ?like. Here > >? ? ? ? ? >? ? ? >? ? ?it is > >? ? ? ? ? >? ? ? >? ? ? >? ? ?:-). Now > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > if it is not wanted like I said, > I can > >? ? ? ? ?backtrack > >? ? ? ? ? >? ? ?and just > >? ? ? ? ? >? ? ? >? ? ?put the > >? ? ? ? ? >? ? ? >? ? ? >? ? ?error > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > checks after each JNI call for > all the > >? ? ? ? ?tests as we are > >? ? ? ? ? >? ? ? >? ? ?porting them. > >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Jc > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > -- > >? ? ? ? ? >? ? ? >? ? ? > > >? ? ? ? ? >? ? ? >? ? ? > Thanks, > >? ? ? ? ? >? ? ? >? ? ? > Jc > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > -- > >? ? ? ? ? >? ? ? > > >? ? ? ? ? >? ? ? > Thanks, > >? ? ? ? ? >? ? ? > Jc > >? ? ? ? ? > > >? ? ? ? ? > > >? ? ? ? ? > > >? ? ? ? ? > -- > >? ? ? ? ? > > >? ? ? ? ? > Thanks, > >? ? ? ? ? > Jc > > > > > > > >? ? ?-- > > > >? ? ?Thanks, > >? ? ?Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Thu Sep 27 18:22:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Sep 2018 11:22:58 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <3ED2E5D2-2215-4DE8-B368-3C4B9BDA48F8@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> <3ED2E5D2-2215-4DE8-B368-3C4B9BDA48F8@oracle.com> Message-ID: <923cc71c-4941-efa3-4ec4-6185043b6a2a@oracle.com> Hi Daniil, It looks great, thank you for the update. I have a couple of more minor comments on the test. 56 testWithDefaultArgs(connector); 57 testWithDefaultArgs2(connector); 58 testWithWildcardPort1(connector); 59 testWithWildcardPort2(connector); ? Please, rename testWithDefaultArgs to testWithDefaultArgs1 ? to make naming consistent. 111 throw new RuntimeException("Test testWithDefaultArgsNegative failed. The argument map was not updated with" + 112 " the bound port number."); 115 // This call should fail since the previous the argument map is already updated with the port ?116 // number of the started listener ? Could you, please, re-balance the above line pairs to make the first line shorter? No need in new webrev if you fix the above. Thanks, Serguei On 9/27/18 11:00 AM, Daniil Titov wrote: > > Hi Serguei, > > Thank you for reviewing this change. Initially I understood the whole > fragment below? (from the Javadoc for > com.sun.jdi.connect.ListeningConnector.startListening() method) as a > direction for the user how to obtain and prepare the argument map > before passing it in startListening() method. > > ? 61????? * The argument map associates argument name strings to instances > ? 62????? * of {@link Connector.Argument}. The default argument map for a > ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. > ? 64????? * Argument map values can be changed, but map entries should not be > ? 65????? * added or deleted. > > But I agree that the last sentence could also mean that the argument > map values could be changes as a result of the method invocation and > in this case the new fragment in the Javadoc is not needed. > > Please review the updated webrev that does not add new Javadoc > fragment and includes other changes you suggested. > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.07/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > > --Daniil > > *From: * > *Organization: *Oracle Corporation > *Date: *Wednesday, September 26, 2018 at 8:12 PM > *To: *Daniil Titov , JC Beyler > > *Cc: *, , > > *Subject: *Re: RFR 8163083: SocketListeningConnector does not allow > invocations with port 0 > > Hi Daniil, > > It is great that you came up the fix for this issue. > Thanks to Gary for the help too. > > I wonder if we could get away without updating the javadoc > of com/sun/jdi/connect/ListeningConnector.java. > Filing a CSR would not be needed then (simple javadoc reformatting > should not require a CSR). > > So, my question is if this new fragment is really needed: > > ? 76????? *

> ? 77????? * If the addressing information provided in {@code > arguments} implies > ? 78????? * the auto detection this information might be updated with > the address > ? 79????? * of the started listener. > > The javadoc for startListening already has this fragment: > > ? 61????? * The argument map associates argument name strings to instances > ? 62????? * of {@link Connector.Argument}. The default argument map for a > ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. > ? 64????? * Argument map values can be changed, but map entries should not be > ? 65????? * added or deleted. > that allows to change the argument map values. > It looks like, it has to be Okay to add the bound port number there. > Please, let me know what you think. > > Some formatting comments to addition to Jc's comments: > > ? 77????? * If the addressing information provided in {@code > arguments} implies > ? 78????? * the auto detection this information might be updated with > the address > ? 79????? * of the started listener. > ? This sentence needs to be split in two: > ? 77????? * If the addressing information provided in {@code > arguments} implies > ? 78????? * the auto detection. This information might be updated with > the address > ? 79????? * of the started listener. > + > +??? protected void updateArgumentMapIfRequired( > +??????????? Map > args,TransportService.ListenKey listener) { > +??? } > + > ? The indent has to be 4, not 8. > +??????? if(isWildcardPort(args)) { > +??????????? String[] address = listener.address().split(":"); > +??????????? if (address.length > 1) { > +??????????????? args.get(ARG_PORT).setValue(address[1]); > +??????????? } > +??????? } > ? A space is missed after the first 'if'. > ? 50???????????????????????? filter(c -> > ? 51????????????? ???????????????????c.name().equals("com.sun.jdi.SocketListen")).findFirst().get(); > > ? This is better to be one liner. > > ? 57???????? testWithDefaultArgs(connector); > ? 58???????? testWithDefaultArgs2(connector); > ? 59???????? testWithWildcardPort(connector); > ? 60???????? testWithWildcardPort2(connector); > ? A suggestion is to rename above as below to have the names more unified: > ? 57???????? testWithDefaultArgs1(connector); > ? 58???????? testWithDefaultArgs2(connector); > ? 59???????? testWithWildcardPort1(connector); > ? 60???????? testWithWildcardPort2(connector); > > Thanks, > Serguei > > On 9/25/18 10:32 AM, Daniil Titov wrote: > > HI JC, > > The webrev is updated to address this. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > *From: *JC Beyler > *Date: *Monday, September 24, 2018 at 8:47 PM > *To: * > *Cc: * > , > , > > > *Subject: *Re: RFR 8163083: SocketListeningConnector does not > allow invocations with port 0 > > Hi Daniil, > > Still looks good to me :) > > Nit: empty line 83 of the new test is not required! > > Jc > > On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov > > wrote: > > Hi Alex, > > Please review the updated webrev that has new test moved to > test/jdk/comsun/jdi/connect folder. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > ?On 9/24/18, 2:56 PM, "Alex Menkov" > wrote: > > ? ? Daniil, > > ? ? Just remembered that SQE requested to not add new tests to > vmTestbase > ? ? (see test/hotspot/jtreg/vmTestbase/README.md) > ? ? Could you please move the test to correct location (I > suppose it's > ? ? test/jdk/com/sun/jdi) > > ? ? --alex > > > ? ? On 09/24/2018 14:30, Alex Menkov wrote: > ? ? > +1 > ? ? > > ? ? > --alex > ? ? > > ? ? > On 09/24/2018 10:39, Gary Adams wrote: > ? ? >> Looks good to me. > ? ? >> > ? ? >> On 9/24/18, 1:25 PM, Daniil Titov wrote: > ? ? >>> Hi Alex and Gary, > ? ? >>> > ? ? >>> Please review the updated patch that includes > suggested changes. > ? ? >>> > ? ? >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > > ? ? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>> > ? ? >>> Thanks! > ? ? >>> --Daniil > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> ?On 9/21/18, 3:59 PM, "Alex > Menkov" > wrote: > ? ? >>> > ? ? >>>? ? ? One more note: > ? ? >>>? ? ? please add "@Override" annotation to the > ? ? >>> SocketListeningConnector.updateArgumentMapIfRequired > ? ? >>> > ? ? >>>? ? ? --alex > ? ? >>> > ? ? >>>? ? ? On 09/21/2018 02:26, gary.adams at oracle.com > wrote: > ? ? >>>? ? ? >? Looks good to me. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? For the javadoc > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?72? ? ? *

> ? ? >>>? ? ? >? ? ?73? ? ? * Ifarguments? > contains addressing > ? ? >>> information. and > ? ? >>>? ? ? >? ? ?74? ? ? * only one connection will be > accepted, the {@link > ? ? >>> #accept accept} method > ? ? >>>? ? ? >? ? ?75? ? ? * can be called immediately without > calling this > ? ? >>> method. > ? ? >>>? ? ? >? ? ?76? ? ? * > ? ? >>>? ? ? >? 77 * If the addressing information provided > ? ? >>> inarguments > ? ? >>>? ? ? >? implies > ? ? >>>? ? ? >? 78 * the auto detection this information might > be updated > ? ? >>> with the address > ? ? >>>? ? ? >? 79 * of the started listener. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?- you could add a

? tag if you want to > maintain the > ? ? >>> spacing in the > ? ? >>>? ? ? >? generated javadoc. > ? ? >>>? ? ? >? ? ?- I've seen other changesets migrating to > {@code ..} from > ? ? >>> the older > ? ? >>>? ? ? >? ... > ? ? >>>? ? ? > > ? ? >>>? ? ? >? It would be good to include some negative testing. > ? ? >>>? ? ? >? Not sure if it is already covered in other > tests, e.g. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ? ?args1 = defaultArguments() > ? ? >>>? ? ? >? ? ? ?startListening(args1) ?// bound port updated > ? ? >>>? ? ? >? ? ? ?startListening(args1) ?// already listening > ? ? >>>? ? ? > > ? ? >>>? ? ? > > ? ? >>>? ? ? >? On 9/20/18 10:59 PM, Daniil Titov wrote: > ? ? >>>? ? ? >>? Please review the change that fixes the issue in > ? ? >>> > com.sun.tools.jdi.SocketListenerConnector.startListening() method. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? When the argument map passed to > startListening() methods has > ? ? >>> the port number unspecified or set to zero the port is > auto detected. > ? ? >>> However,? the consequent call of startListening() > methods with > ? ? >>> unspecified port number fails rather than starts a new > listener on > ? ? >>> auto detected port. This happens since the original > argument map > ? ? >>> passed to the startListening() methods is used as a > key to store the > ? ? >>> mapping to the started listeners. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? The fix ensures that in cases when the port > is auto detected > ? ? >>> the argument map is updated with the bound port number. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Mach5 vmTestbase_nsk_jdi tests successfully > passed. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? > Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>>? ? ? >>? > Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Thanks! > ? ? >>>? ? ? >>? --Daniil > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? > > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >> > > > > > -- > > Thanks, > > Jc > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Thu Sep 27 18:34:40 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 27 Sep 2018 11:34:40 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> Message-ID: <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> Very, very nice! Thanks for adding the comment and renaming the class! Ship it! Cheers, Mikael > On Sep 27, 2018, at 10:45 AM, JC Beyler wrote: > > Hi Mikael and David, > > @David: I thought it was implicit but did not want to presume on this one because my goal is to start propagating this new class in the test base and get the checks to be done implicitly so I was probably being over-cautious > @Mikael: done and done, what do you think of the comment here : http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html > > For all, the new webrev is here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > Thanks, > Jc > > On Thu, Sep 27, 2018 at 6:03 AM David Holmes > wrote: > Sorry Jc, I thought my LGTM was implicit. :) > > Thanks, > David > > On 26/09/2018 11:52 PM, JC Beyler wrote: > > Ping on this, anybody have time to do a review and give a LGTM? Or David > > if you have time and will to provide an explicit LGTM :) > > > > Thanks, > > Jc > > > > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > > >> wrote: > > > > Hi David, > > > > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting > > for an explicit LGTM from you or from someone else on this list to > > do a review. > > > > Thanks again for your help, > > Jc > > > > On Sun, Sep 23, 2018 at 9:22 AM David Holmes > > >> wrote: > > > > Hi Jc, > > > > I don't think it is an issue for this to go ahead. If the static > > analysis tool has an issue then we can either find out how to > > teach it > > about this code structure, or else flag the issues as false > > positives. > > I'd be relying on one of the serviceability team here to handle > > that if > > the problem arises. > > > > Thanks, > > David > > > > On 23/09/2018 12:17 PM, JC Beyler wrote: > > > Hi David, > > > > > > No worries with the time to answer; I appreciate the review! > > > > > > That's a fair point. Is it possible to "describe" to the > > static analysis > > > tool to "trust" calls made in the SafeJNIEnv class? > > > > > > Otherwise, do you have any idea on how to go forward? For > > what it's > > > worth, this current webrev does not try to replace exception > > checking > > > with the SafeJNIEnv (it actually adds it), so for now the > > > question/solution could be delayed. I could continue working > > on this in > > > the scope of both the nsk/gc/lock/jniref code base and the > > NSK_VERIFIER > > > macro removal and we can look at how to tackle the cases > > where the tests > > > are actually calling exception checking (I know my > > heapmonitor does for > > > example). > > > > > > Let me know what you think and thanks for the review, > > > Jc > > > > > > > > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > > > > > > > > >>> wrote: > > > > > > Hi Jc, > > > > > > Sorry for the delay on getting back to this but I'm > > travelling at the > > > moment. > > > > > > This looks quite neat. Thanks also to Alex for all the > > suggestions. > > > > > > My only remaining concern is that static analysis tools > > may not like > > > this because they may not be able to determine that we > > won't make > > > subsequent JNI calls when an exception happens in the > > first. That's not > > > a reason not to do this of course, just flagging that we > > may have to do > > > something to deal with that problem. > > > > > > Thanks, > > > David > > > > > > On 20/09/2018 11:56 AM, JC Beyler wrote: > > > > Hi Alex, > > > > > > > > Done here, thanks for the review: > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > Thanks again! > > > > Jc > > > > > > > > > > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov > > > > > > > > >> > > > > > > > > > > > > >>>> wrote: > > > > > > > > Hi Jc, > > > > > > > > Looks good to me. > > > > A minor note: > > > > - I'd move ErrorHandler typedef to SafeJNIEnv > > class to avoid > > > global > > > > namespece pollution (ErrorHandler is too generic > > name). > > > > > > > > --alex > > > > > > > > On 09/19/2018 15:56, JC Beyler wrote: > > > > > Hi Alex, > > > > > > > > > > I've updated the webrev to: > > > > > Webrev: > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > That webrev has the code that is shown here in > > snippets. > > > > > > > > > > > > > > > Thanks for the reviews, I've relatively > > followed your reviews > > > > except for > > > > > one detail due to me wanting to handle the > > NSK_JNI_VERIFY > > > macros via > > > > > this system as well later down the road. For an > > example: > > > > > > > > > > We currently have in the code: > > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > > NSK_CPP_STUB2(GetObjectClass, > > > > > pEnv, mhToCall)) != NULL) ) > > > > > > > > > > 1) The NSK_CPP_STUB2 is trivially removed with > > a refactor > > > > (JDK-8210728) > > > > > > > > to: > > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = > > > pEnv->GetObjectClass(pEnv, > > > > > mhToCall)) != NULL) ) > > > > > > > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove > > it to and it > > > > becomes via > > > > > this wrapping of JNIEnv: > > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, > > mhToCall)) ) > > > > > > > > > > 3) Then, via removing the assignment, we'd > > arrive to a: > > > > > mhClass = pEnv->GetObjectClass(pEnv, mhToCall)); > > > > > if (!mhClass) > > > > > > > > > > Without any loss of checking for failures, etc. > > > > > > > > > > So that is my motivation for most of this work > > with a concrete > > > > example > > > > > (hopefully it helps drive this conversation). > > > > > > > > > > I inlined my answers here, let me know what you > > think. > > > > > > > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov > > > > > > > > > >> > > > > > > > > >>> > > > > > > > > > > > > > >> > > > > > > > > > > > > >>>>> wrote: > > > > > > > > > > Hi Jc, > > > > > > > > > > Updated tests looks good. > > > > > Some notes about implementation. > > > > > > > > > > - FatalOnException implements both > > verification and error > > > > handling > > > > > It would be better to separate them (and > > this makes > > > easy to > > > > implement > > > > > error handling different from > > JNIEnv::FatalError). > > > > > The simplest way is to define error handler as > > > > > class SafeJNIEnv { > > > > > public: > > > > > typedef void (*ErrorHandler)(JNIEnv > > *env, const > > > char* > > > > errorMsg); > > > > > // error handler which terminates jvm > > by using > > > FatalError() > > > > > static void FatalError(JNIEnv *env, > > const char > > > *errrorMsg); > > > > > > > > > > SafeJNIEnv(JNIEnv* jni_env, ErrorHandler > > > errorHandler = > > > > > FatalError); > > > > > (SafeJNIEnv methods should create > > FatalOnException objects > > > > passing > > > > > errorHandler) > > > > > > > > > > > > > > > > > > > > Agreed, I tried to keep the code simple. The > > concepts you > > > talk about > > > > > here are generally what I reserve for when I > > need it (ie > > > > extensions and > > > > > handling new cases). But a lot are going to be > > needed soon > > > so I > > > > think it > > > > > is a good time to iron the code out now on this > > "simple" > > > webrev. > > > > > > > > > > So done for this. > > > > > > > > > > > > > > > > > > > > - FatalOnException is used in SafeJNIEnv > > methods as > > > > > FatalOnException marker(this, "msg"); > > > > > ret = > > > > > (optional)marker.check_for_null(ret); > > > > > return ret; > > > > > But actually I'd call it something like > > > JNICallResultVerifier and > > > > > create > > > > > the object after JNI call. like > > > > > ret = > > > > > JNICallResultVerifier(this, "msg") > > > > > (optional).notNull(ret); > > > > > return ret; > > > > > or even (if you like such syntax sugar) you > > can define > > > > > template > > > > > T resultNotNull(T result) { > > > > > notNull(result); > > > > > return result; > > > > > } > > > > > and do > > > > > ret = > > > > > return JNICallResultVerifier(this, > > > "msg").resultNotNull(ret); > > > > > > > > > > > > > > > So I renamed FatalOnException to now being > > JNIVerifier. > > > > > > > > > > Though I like it, I don't think we can do it, > > except if we > > > do it > > > > > slightly differently: > > > > > I'm trying to solve two problems with one stone: > > > > > - How to check for returns of JNI calls in > > the way that is > > > > done here > > > > > - How to remove NSK_JNI_VERIFY* (from > > > nsk/share/jni/jni_tools) > > > > > > > > > > However, the NSK_JNI_VERIFY need to start a > > tracing system > > > before > > > > the > > > > > call to JNI, so it won't work this way. (Side > > question > > > would be > > > > do we > > > > > still care about the tracing in NSK_JNI_VERIFY, > > if we > > > don't then > > > > your > > > > > solution works well in most situations). > > > > > > > > > > My vision or intuition is that we would throw a > > template > > > at some > > > > point > > > > > on SafeJNIEnv to handle both cases and have > > JNIVerifier > > > become a > > > > > specialization in certain cases and something > > different > > > for the > > > > > NSK_JNI_VERIFY case (or have a different > > constructor to enable > > > > tracing). > > > > > But for now, I offer the implementation that does: > > > > > > > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) { > > > > > JNIVerifier marker(this, > > "GetObjectClass"); > > > > > return > > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > > > > > } > > > > > > > > > > and: > > > > > > > > > > void SafeJNIEnv::SetObjectField(jobject obj, > > jfieldID > > > field, jobject > > > > > value) { > > > > > JNIVerifier<> marker(this, "SetObjectField"); > > > > > _jni_env->SetObjectField(obj, field, value); > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > - you added #include in the test > > (and you have to > > > > add it to > > > > > every test). > > > > > It would be simpler to add the include to > > > SafeJNIEnv.hpp and > > > > define > > > > > typedef std::unique_ptr > > SafeJNIEnvPtr; > > > > > Then each in the test methods: > > > > > SafeJNIEnvPtr env(new SafeJNIEnv(jni_env)); > > > > > or you can add > > > > > static SafeJNIEnv::SafeJNIEnvPtr > > wrap(JNIEnv* jni_env, > > > > ErrorHandler > > > > > errorHandler = fatalError) > > > > > and get > > > > > SafeJNIEnvPtr env = > > SafeJNIEnv::wrap(jni_env); > > > > > > > > > > > > > > > Done, I like that, even less code change to > > tests then. > > > > > > > > > > > > > > > > > > > > - it would be better to wrap internal classes > > > > (FatalOnException) into > > > > > unnamed namespace - this helps to avoid > > conflicts with > > > other > > > > classes) > > > > > > > > > > - FatalOnException::check_for_null(void* ptr) > > > > > should be > > > > > FatalOnException::check_for_null(const > > void* ptr) > > > > > And calling the method you don't need > > reinterpret_cast > > > > > > > > > > > > > > > Also done, it got renamed to ResultNotNull, is > > using a > > > template > > > > now, but > > > > > agreed, that worked. > > > > > Thanks again for the review, > > > > > Jc > > > > > > > > > > > > > > > --alex > > > > > > > > > > > > > > > On 09/18/2018 11:07, JC Beyler wrote: > > > > > > Hi David, > > > > > > > > > > > > Thanks for the quick review and > > thoughts. I have > > > now a new > > > > > version here > > > > > > that addresses your comments: > > > > > > > > > > > > Webrev: > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > > > I've also inlined my answers/comments. > > > > > > > > > > > > > > > > > > > > > > > > > I've slowly started working on > > JDK-8191519 > > > > > > > > > > >. > > > > > However before > > > > > > > starting to really refactor all > > the tests, I > > > > thought I'd > > > > > get a few > > > > > > > opinions. I am working on > > internalizing the > > > error > > > > handling > > > > > of JNI > > > > > > calls > > > > > > > via a SafeJNIEnv class that > > redefines all > > > the JNI > > > > calls to > > > > > add an > > > > > > error > > > > > > > checker. > > > > > > > > > > > > > > The advantage is that the test > > code will > > > look and > > > > feel like > > > > > > normal JNI > > > > > > > code and calls but will have the > > checks we > > > want to have > > > > > for our > > > > > > tests. > > > > > > > > > > > > Not sure I get that. Normal JNI code > > has to > > > check for > > > > > errors/exceptions > > > > > > after every call. The tests need > > those checks too. > > > > Today they are > > > > > > explicit, with this change they become > > > implicit. Not sure > > > > > what we are > > > > > > gaining here ?? > > > > > > > > > > > > > > > > > > In my humble opinion, having the error > > checking out > > > of the way > > > > > allows > > > > > > the code reader to concentrate on the > > JNI code while > > > > maintaining > > > > > error > > > > > > checking. We use something similar > > internally, so > > > perhaps I'm > > > > > biased to > > > > > > it :-). > > > > > > If this is not a desired/helpful > > "feature" to simplify > > > > tests in > > > > > general, > > > > > > I will backtrack it and just add the > > explicit tests > > > to the > > > > native > > > > > code > > > > > > of the locks for the fix > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. > > > > > > > > > > > > Let me however try to make my case and > > let me know what > > > > you all > > > > > think! > > > > > > > > > > > > > > > > > > > If agreed with this, we can > > augment the > > > SafeJNIEnv > > > > class > > > > > as needed. > > > > > > > Also, if the tests require > > something else > > > than fatal > > > > > errors, we > > > > > > can add > > > > > > > a different marker and make it a > > parameter > > > to the > > > > base class. > > > > > > > > > > > > > > Webrev: > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8210842 > > > > > > > > > > > > > > Let me know what you think, > > > > > > > > > > > > Two initial suggestions: > > > > > > > > > > > > 1. FatalOnException should be > > constructed with a > > > > description > > > > > string so > > > > > > that it can report the failing > > operation when > > > calling > > > > > FatalError rather > > > > > > than the general "Problem with a JNI > > call". > > > > > > > > > > > > > > > > > > Agreed with you, the new webrev produces: > > > > > > > > > > > > FATAL ERROR in native method: GetObjectClass > > > > > > at > > > > > > > > > > > > > > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) > > > > > > at > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > > Method) > > > > > > at > > > > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > at > > > > > > > > > > > > > > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) > > > > > > at > > > > > > > > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) > > > > > > > > > > > > > > > > > > and for a return NULL in NewGlobalRef, > > we would get > > > > automatically: > > > > > > > > > > > > FATAL ERROR in native method: > > NewGlobalRef:Return > > > is NULL > > > > > > at > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native > > > > > Method) > > > > > > > > > > > > at > > > > > > > > > > > > > > > > > > > > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again as we port and simplify more tests > > (I'll only > > > do the > > > > locks > > > > > for now > > > > > > and we can figure out the next steps as > > start > > > working on > > > > moving > > > > > tests > > > > > > out of vmTestbase), > > > > > > we can add, if needed, other exception > > handlers > > > that don't > > > > throw > > > > > or do > > > > > > other things depending on the JNI method > > outputs. > > > > > > > > > > > > > > > > > > 2. Make the local SafeJNIEnv a > > pointer called > > > env so > > > > that the > > > > > change is > > > > > > less disruptive. All the env->op() > > calls will > > > remain > > > > and only > > > > > the local > > > > > > error checking will be removed. > > > > > > > > > > > > > > > > > > Done, I used a unique_ptr to make the object > > > > > created/destroyed/available > > > > > > as a pointer do-able in one line: > > > > > > std::unique_ptr env(new > > > SafeJNIEnv(jni_env)); > > > > > > > > > > > > and then you can see that, as you > > mentioned, the > > > disruption to > > > > > the code > > > > > > is much less: > > > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Basically the tests now become internal > > to the > > > SafeJNIEnv > > > > and the > > > > > code > > > > > > now only contains the JNI calls > > happening but we > > > are protected > > > > > and will > > > > > > fail any test that has an exception or a > > NULL > > > return for the > > > > > call. Of > > > > > > course, this is not 100% proof in terms > > of not > > > having any > > > > error > > > > > handling > > > > > > in the test but in some cases like this, > > the new > > > code seems to > > > > > just work > > > > > > better: > > > > > > > > > > > > > > > > > > > > > > > > > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The switch from, e.g., checking NULL > > returns to > > > > checking for > > > > > pending > > > > > > exceptions, need to be sure that the > > JNI operations > > > > clearly > > > > > specify > > > > > > that > > > > > > NULL implies there will be an exception > > > pending. This > > > > change > > > > > may be an > > > > > > issue for static code analysis if > > not smart > > > enough to > > > > > understand the > > > > > > RAII wrappers. > > > > > > > > > > > > > > > > > > Agreed, I fixed it to be more strict and > > say: in > > > normal test > > > > > handling, > > > > > > the JNI calls should never return NULL > > or throw an > > > > exception. This > > > > > > should hold for tests I imagine but if > > not we can add a > > > > different > > > > > call > > > > > > verifier as we go. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > David > > > > > > > > > > > > > Jc > > > > > > > > > > > > > > > > > > > > > > > > Let me know what you all think. When > > talking about it a > > > > bit, I had > > > > > > gotten some interest to see what it > > would look > > > like. Here > > > > it is > > > > > :-). Now > > > > > > if it is not wanted like I said, I can > > backtrack > > > and just > > > > put the > > > > > error > > > > > > checks after each JNI call for all the > > tests as we are > > > > porting them. > > > > > > Jc > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Thanks, > > > > > Jc > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 27 18:33:40 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Sep 2018 11:33:40 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <923cc71c-4941-efa3-4ec4-6185043b6a2a@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> <3ED2E5D2-2215-4DE8-B368-3C4B9BDA48F8@oracle.com> <923cc71c-4941-efa3-4ec4-6185043b6a2a@oracle.com> Message-ID: Just noticed one more minor issue: +import java.util.Collection; +import java.util.Iterator; +import java.util.LinkedHashMap; ?It seems the above imports are not really used and can be removed. Thanks, Serguei On 9/27/18 11:22 AM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > It looks great, thank you for the update. > I have a couple of more minor comments on the test. > > 56 testWithDefaultArgs(connector); > 57 testWithDefaultArgs2(connector); > 58 testWithWildcardPort1(connector); > 59 testWithWildcardPort2(connector); > > ? Please, rename testWithDefaultArgs to testWithDefaultArgs1 > ? to make naming consistent. > > 111 throw new RuntimeException("Test testWithDefaultArgsNegative failed. The argument map was not updated with" + > 112 " the bound port number."); > > 115 // This call should fail since the previous the argument map is already updated with the port > ?116 // number of the started listener > > ? Could you, please, re-balance the above line pairs to make the first > line shorter? > > No need in new webrev if you fix the above. > > Thanks, > Serguei > > On 9/27/18 11:00 AM, Daniil Titov wrote: >> >> Hi Serguei, >> >> Thank you for reviewing this change. Initially I understood the whole >> fragment below? (from the Javadoc for >> com.sun.jdi.connect.ListeningConnector.startListening() method) as a >> direction for the user how to obtain and prepare the argument map >> before passing it in startListening() method. >> >> ? 61????? * The argument map associates argument name strings to instances >> ? 62????? * of {@link Connector.Argument}. The default argument map for a >> ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. >> ? 64????? * Argument map values can be changed, but map entries should not be >> ? 65????? * added or deleted. >> >> But I agree that the last sentence could also mean that the argument >> map values could be changes as a result of the method invocation and >> in this case the new fragment in the Javadoc is not needed. >> >> Please review the updated webrev that does not add new Javadoc >> fragment and includes other changes you suggested. >> >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.07/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >> >> Thanks! >> >> --Daniil >> >> *From: * >> *Organization: *Oracle Corporation >> *Date: *Wednesday, September 26, 2018 at 8:12 PM >> *To: *Daniil Titov , JC Beyler >> >> *Cc: *, , >> >> *Subject: *Re: RFR 8163083: SocketListeningConnector does not allow >> invocations with port 0 >> >> Hi Daniil, >> >> It is great that you came up the fix for this issue. >> Thanks to Gary for the help too. >> >> I wonder if we could get away without updating the javadoc >> of com/sun/jdi/connect/ListeningConnector.java. >> Filing a CSR would not be needed then (simple javadoc reformatting >> should not require a CSR). >> >> So, my question is if this new fragment is really needed: >> >> ? 76????? *

>> ? 77????? * If the addressing information provided in {@code >> arguments} implies >> ? 78????? * the auto detection this information might be updated with >> the address >> ? 79????? * of the started listener. >> >> The javadoc for startListening already has this fragment: >> >> ? 61????? * The argument map associates argument name strings to instances >> ? 62????? * of {@link Connector.Argument}. The default argument map for a >> ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. >> ? 64????? * Argument map values can be changed, but map entries should not be >> ? 65????? * added or deleted. >> that allows to change the argument map values. >> It looks like, it has to be Okay to add the bound port number there. >> Please, let me know what you think. >> >> Some formatting comments to addition to Jc's comments: >> >> ? 77????? * If the addressing information provided in {@code >> arguments} implies >> ? 78????? * the auto detection this information might be updated with >> the address >> ? 79????? * of the started listener. >> ? This sentence needs to be split in two: >> ? 77????? * If the addressing information provided in {@code >> arguments} implies >> ? 78????? * the auto detection. This information might be updated >> with the address >> ? 79????? * of the started listener. >> + >> +??? protected void updateArgumentMapIfRequired( >> +??????????? Map >> args,TransportService.ListenKey listener) { >> +??? } >> + >> ? The indent has to be 4, not 8. >> +??????? if(isWildcardPort(args)) { >> +??????????? String[] address = listener.address().split(":"); >> +??????????? if (address.length > 1) { >> +??????????????? args.get(ARG_PORT).setValue(address[1]); >> +??????????? } >> +??????? } >> ? A space is missed after the first 'if'. >> ? 50???????????????????????? filter(c -> >> ? 51????????????? ???????????????????c.name().equals("com.sun.jdi.SocketListen")).findFirst().get(); >> >> ? This is better to be one liner. >> >> ? 57???????? testWithDefaultArgs(connector); >> ? 58???????? testWithDefaultArgs2(connector); >> ? 59???????? testWithWildcardPort(connector); >> ? 60???????? testWithWildcardPort2(connector); >> ? A suggestion is to rename above as below to have the names more unified: >> ? 57???????? testWithDefaultArgs1(connector); >> ? 58???????? testWithDefaultArgs2(connector); >> ? 59???????? testWithWildcardPort1(connector); >> ? 60???????? testWithWildcardPort2(connector); >> >> Thanks, >> Serguei >> >> On 9/25/18 10:32 AM, Daniil Titov wrote: >> >> HI JC, >> >> The webrev is updated to address this. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >> >> Thanks! >> --Daniil >> >> *From: *JC Beyler >> *Date: *Monday, September 24, 2018 at 8:47 PM >> *To: * >> *Cc: * >> , >> , >> >> >> *Subject: *Re: RFR 8163083: SocketListeningConnector does not >> allow invocations with port 0 >> >> Hi Daniil, >> >> Still looks good to me :) >> >> Nit: empty line 83 of the new test is not required! >> >> Jc >> >> On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov >> > wrote: >> >> Hi Alex, >> >> Please review the updated webrev that has new test moved to >> test/jdk/comsun/jdi/connect folder. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >> >> Thanks! >> --Daniil >> >> >> ?On 9/24/18, 2:56 PM, "Alex Menkov" > > wrote: >> >> ? ? Daniil, >> >> ? ? Just remembered that SQE requested to not add new tests >> to vmTestbase >> ? ? (see test/hotspot/jtreg/vmTestbase/README.md) >> ? ? Could you please move the test to correct location (I >> suppose it's >> ? ? test/jdk/com/sun/jdi) >> >> ? ? --alex >> >> >> ? ? On 09/24/2018 14:30, Alex Menkov wrote: >> ? ? > +1 >> ? ? > >> ? ? > --alex >> ? ? > >> ? ? > On 09/24/2018 10:39, Gary Adams wrote: >> ? ? >> Looks good to me. >> ? ? >> >> ? ? >> On 9/24/18, 1:25 PM, Daniil Titov wrote: >> ? ? >>> Hi Alex and Gary, >> ? ? >>> >> ? ? >>> Please review the updated patch that includes >> suggested changes. >> ? ? >>> >> ? ? >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >> >> ? ? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >> ? ? >>> >> ? ? >>> Thanks! >> ? ? >>> --Daniil >> ? ? >>> >> ? ? >>> >> ? ? >>> >> ? ? >>> >> ? ? >>> ?On 9/21/18, 3:59 PM, "Alex >> Menkov"> > wrote: >> ? ? >>> >> ? ? >>>? ? ? One more note: >> ? ? >>>? ? ? please add "@Override" annotation to the >> ? ? >>> SocketListeningConnector.updateArgumentMapIfRequired >> ? ? >>> >> ? ? >>>? ? ? --alex >> ? ? >>> >> ? ? >>>? ? ? On 09/21/2018 02:26, gary.adams at oracle.com >> wrote: >> ? ? >>>? ? ? >? Looks good to me. >> ? ? >>>? ? ? > >> ? ? >>>? ? ? >? For the javadoc >> ? ? >>>? ? ? > >> ? ? >>>? ? ? >? ? ?72? ? ? *

>> ? ? >>>? ? ? >? ? ?73? ? ? * Ifarguments? >> contains addressing >> ? ? >>> information. and >> ? ? >>>? ? ? >? ? ?74? ? ? * only one connection will be >> accepted, the {@link >> ? ? >>> #accept accept} method >> ? ? >>>? ? ? >? ? ?75? ? ? * can be called immediately >> without calling this >> ? ? >>> method. >> ? ? >>>? ? ? >? ? ?76? ? ? * >> ? ? >>>? ? ? >? 77 * If the addressing information provided >> ? ? >>> inarguments >> ? ? >>>? ? ? >? implies >> ? ? >>>? ? ? >? 78 * the auto detection this information >> might be updated >> ? ? >>> with the address >> ? ? >>>? ? ? >? 79 * of the started listener. >> ? ? >>>? ? ? > >> ? ? >>>? ? ? >? ? ?- you could add a

? tag if you want to >> maintain the >> ? ? >>> spacing in the >> ? ? >>>? ? ? >? generated javadoc. >> ? ? >>>? ? ? >? ? ?- I've seen other changesets migrating to >> {@code ..} from >> ? ? >>> the older >> ? ? >>>? ? ? > ... >> ? ? >>>? ? ? > >> ? ? >>>? ? ? >? It would be good to include some negative >> testing. >> ? ? >>>? ? ? >? Not sure if it is already covered in other >> tests, e.g. >> ? ? >>>? ? ? > >> ? ? >>>? ? ? >? ? ? ?args1 = defaultArguments() >> ? ? >>>? ? ? > ?startListening(args1)? ?// bound port updated >> ? ? >>>? ? ? > ?startListening(args1)? ?// already listening >> ? ? >>>? ? ? > >> ? ? >>>? ? ? > >> ? ? >>>? ? ? >? On 9/20/18 10:59 PM, Daniil Titov wrote: >> ? ? >>>? ? ? >>? Please review the change that fixes the >> issue in >> ? ? >>> >> com.sun.tools.jdi.SocketListenerConnector.startListening() >> method. >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >>? When the argument map passed to >> startListening() methods has >> ? ? >>> the port number unspecified or set to zero the port >> is auto detected. >> ? ? >>> However,? the consequent call of startListening() >> methods with >> ? ? >>> unspecified port number fails rather than starts a >> new listener on >> ? ? >>> auto detected port. This happens since the original >> argument map >> ? ? >>> passed to the startListening() methods is used as a >> key to store the >> ? ? >>> mapping to the started listeners. >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >>? The fix ensures that in cases when the port >> is auto detected >> ? ? >>> the argument map is updated with the bound port number. >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >>? Mach5 vmTestbase_nsk_jdi tests successfully >> passed. >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >>? >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >> ? ? >>>? ? ? >>? >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >> >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >>? Thanks! >> ? ? >>>? ? ? >>? --Daniil >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? >> >> ? ? >>>? ? ? > >> ? ? >>> >> ? ? >>> >> ? ? >>> >> ? ? >> >> >> >> >> >> -- >> >> Thanks, >> >> Jc >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 27 18:34:39 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 27 Sep 2018 11:34:39 -0700 Subject: JDK-8203350: Crash in vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java In-Reply-To: <5BACCAB0.1050806@oracle.com> References: <5BACCAB0.1050806@oracle.com> Message-ID: Hi Gary, Aren't you just hiding a potential jvmti bug with this change? If you think this is a test bug and this is a proper fix, I'd like to see an explanation of how the test is causing the crash. The explanation would need to involve native code, since pure java should never crash. thanks, Chris On 9/27/18 5:18 AM, Gary Adams wrote: > I've been unsuccessful trying to reproduce the failure in hs201t002. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203350 > > Colleen made a comment on the bug that the reference > from hs201t002a to class hs201t002 might be an issue > for the redefined class. > > I found in test hs201t001 that an intentional reference > before entering hs201t001a.doInit() is made to avoid > that classloader operation. > > It's not clear to me why that was done, but the same workaround > could be used in hs201t002a, if it would make the test more robust. > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java > > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java > @@ -26,6 +26,7 @@ > ?public class hs201t002a extends Exception { > > ???? public hs201t002a () { > +??????? System.out.println("Current step: " + hs201t002.currentStep); > // Avoid calling classloader to find hs201t002 in doInit() > ???????? doInit(); > ???? } > From gary.adams at oracle.com Thu Sep 27 18:44:25 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 27 Sep 2018 14:44:25 -0400 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: References: <5BA3DFFE.5090201@oracle.com> Message-ID: <5BAD2509.7020407@oracle.com> Speaking of not being bullet proof, during testing of the fix to wait for a specific prompt an intermittent failure was observed. ... Sending command: trace methods 0x2a9 reply[0]: MyThread-0[1] Sending command: cont WARNING: message not recieved: MyThread-0[1] Remaining debugger output follows: reply[0]:> reply[1]: Method exited: return value =, "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), line=93 bci=14 reply[2]: 93 } reply[3]: reply[4]: MyThread-0[1] # ERROR: Caught unexpected exception while executing the test: nsk.share.Failure: Expected message not received during 420200 milliseconds: ... The wait for message times out looking for "MyThread-0[1]". A WARNING is printed and the "remaining debugger output" shows that "MyThread-0[1]" is in the buffer. I'm still investigating why the message match is not found. Adding a final check before failing the wait for message seems to workaround the problem. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java @@ -515,10 +515,11 @@ long delta = 200; // time in milliseconds to wait at every iteration. long total = 0; // total time has waited. long max = getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; // maximum time to wait. + int found = 0; Object dummy = new Object(); while ((total += delta) <= max) { - int found = 0; + found = 0; // search for message { @@ -553,6 +554,12 @@ log.display("WARNING: message not recieved: " + message); log.display("Remaining debugger output follows:"); receiveReply(startPos); + + // One last chance + found = findMessage(startPos, message); + if (found > 0) { + return found; + } throw new Failure("Expected message not received during " + total + " milliseconds:" + "\n\t" + message); } On 9/20/18, 5:47 PM, Chris Plummer wrote: > Looks good. Still not bullet proof, but I'm not sure it's possible to > write tests like this in a way that will work no matter what output is > produced by the method enter/exit events. > > Chris > > On 9/20/18 10:59 AM, Gary Adams wrote: >> The test failure has been identified due to the "int[2]" >> being misrecognized as a compound prompt. This caused a cont >> command to be sent prematurely. >> >> The proposed fix waits for the correct prompt before >> advancing to the next command. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >> >> Testing is in progress. > > > From daniil.x.titov at oracle.com Thu Sep 27 18:50:01 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 27 Sep 2018 11:50:01 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> <3ED2E5D2-2215-4DE8-B368-3C4B9BDA48F8@oracle.com> <923cc71c-4941-efa3-4ec4-6185043b6a2a@oracle.com> Message-ID: <350E9BBD-1F19-46F6-A91E-AEAA1D0466D7@oracle.com> Hi Serguei, The webrev was updated to address all these comments. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.08 Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: Organization: Oracle Corporation Date: Thursday, September 27, 2018 at 11:33 AM To: Daniil Titov , JC Beyler Cc: , , Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Just noticed one more minor issue: +import java.util.Collection; +import java.util.Iterator; +import java.util.LinkedHashMap; It seems the above imports are not really used and can be removed. Thanks, Serguei On 9/27/18 11:22 AM, serguei.spitsyn at oracle.com wrote: Hi Daniil, It looks great, thank you for the update. I have a couple of more minor comments on the test. ? 56???????? testWithDefaultArgs(connector); ? 57???????? testWithDefaultArgs2(connector); ? 58???????? testWithWildcardPort1(connector); ? 59???????? testWithWildcardPort2(connector); Please, rename testWithDefaultArgs to testWithDefaultArgs1 to make naming consistent. 111???????????? throw new RuntimeException("Test testWithDefaultArgsNegative failed. The argument map was not updated with" + 112???????????????????? " the bound port number."); 115???????????? // This call should fail since the previous the argument map is already updated with the port 116???????????? // number of the started listener Could you, please, re-balance the above line pairs to make the first line shorter? No need in new webrev if you fix the above. Thanks, Serguei On 9/27/18 11:00 AM, Daniil Titov wrote: Hi Serguei, Thank you for reviewing this change. Initially I understood the whole fragment below (from the Javadoc for com.sun.jdi.connect.ListeningConnector.startListening() method) as a direction for the user how to obtain and prepare the argument map before passing it in startListening() method. 61 * The argument map associates argument name strings to instances 62 * of {@link Connector.Argument}. The default argument map for a 63 * connector can be obtained through {@link Connector#defaultArguments}. 64 * Argument map values can be changed, but map entries should not be 65 * added or deleted. But I agree that the last sentence could also mean that the argument map values could be changes as a result of the method invocation and in this case the new fragment in the Javadoc is not needed. Please review the updated webrev that does not add new Javadoc fragment and includes other changes you suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.07/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: Organization: Oracle Corporation Date: Wednesday, September 26, 2018 at 8:12 PM To: Daniil Titov , JC Beyler Cc: , , Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Hi Daniil, It is great that you came up the fix for this issue. Thanks to Gary for the help too. I wonder if we could get away without updating the javadoc of com/sun/jdi/connect/ListeningConnector.java. Filing a CSR would not be needed then (simple javadoc reformatting should not require a CSR). So, my question is if this new fragment is really needed: 76 *

77 * If the addressing information provided in {@code arguments} implies 78 * the auto detection this information might be updated with the address 79 * of the started listener. The javadoc for startListening already has this fragment: 61 * The argument map associates argument name strings to instances 62 * of {@link Connector.Argument}. The default argument map for a 63 * connector can be obtained through {@link Connector#defaultArguments}. 64 * Argument map values can be changed, but map entries should not be 65 * added or deleted. that allows to change the argument map values. It looks like, it has to be Okay to add the bound port number there. Please, let me know what you think. Some formatting comments to addition to Jc's comments: 77 * If the addressing information provided in {@code arguments} implies 78 * the auto detection this information might be updated with the address 79 * of the started listener. This sentence needs to be split in two: 77 * If the addressing information provided in {@code arguments} implies 78 * the auto detection. This information might be updated with the address 79 * of the started listener. + + protected void updateArgumentMapIfRequired( + Map args,TransportService.ListenKey listener) { + } + The indent has to be 4, not 8. + if(isWildcardPort(args)) { + String[] address = listener.address().split(":"); + if (address.length > 1) { + args.get(ARG_PORT).setValue(address[1]); + } + } A space is missed after the first 'if'. 50 filter(c -> 51 c.name().equals("com.sun.jdi.SocketListen")).findFirst().get(); This is better to be one liner. 57 testWithDefaultArgs(connector); 58 testWithDefaultArgs2(connector); 59 testWithWildcardPort(connector); 60 testWithWildcardPort2(connector); A suggestion is to rename above as below to have the names more unified: 57 testWithDefaultArgs1(connector); 58 testWithDefaultArgs2(connector); 59 testWithWildcardPort1(connector); 60 testWithWildcardPort2(connector); Thanks, Serguei On 9/25/18 10:32 AM, Daniil Titov wrote: HI JC, The webrev is updated to address this. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: JC Beyler Date: Monday, September 24, 2018 at 8:47 PM To: Cc: , , Subject: Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 Hi Daniil, Still looks good to me :) Nit: empty line 83 of the new test is not required! Jc On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov wrote: Hi Alex, Please review the updated webrev that has new test moved to test/jdk/comsun/jdi/connect folder. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil ?On 9/24/18, 2:56 PM, "Alex Menkov" wrote: Daniil, Just remembered that SQE requested to not add new tests to vmTestbase (see test/hotspot/jtreg/vmTestbase/README.md) Could you please move the test to correct location (I suppose it's test/jdk/com/sun/jdi) --alex On 09/24/2018 14:30, Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 10:39, Gary Adams wrote: >> Looks good to me. >> >> On 9/24/18, 1:25 PM, Daniil Titov wrote: >>> Hi Alex and Gary, >>> >>> Please review the updated patch that includes suggested changes. >>> >>> http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >>> Thanks! >>> --Daniil >>> >>> >>> >>> >>> ?On 9/21/18, 3:59 PM, "Alex Menkov" wrote: >>> >>> One more note: >>> please add "@Override" annotation to the >>> SocketListeningConnector.updateArgumentMapIfRequired >>> >>> --alex >>> >>> On 09/21/2018 02:26, gary.adams at oracle.com wrote: >>> > Looks good to me. >>> > >>> > For the javadoc >>> > >>> > 72 *

>>> > 73 * Ifarguments contains addressing >>> information. and >>> > 74 * only one connection will be accepted, the {@link >>> #accept accept} method >>> > 75 * can be called immediately without calling this >>> method. >>> > 76 * >>> > 77 * If the addressing information provided >>> inarguments >>> > implies >>> > 78 * the auto detection this information might be updated >>> with the address >>> > 79 * of the started listener. >>> > >>> > - you could add a

tag if you want to maintain the >>> spacing in the >>> > generated javadoc. >>> > - I've seen other changesets migrating to {@code ..} from >>> the older >>> > ... >>> > >>> > It would be good to include some negative testing. >>> > Not sure if it is already covered in other tests, e.g. >>> > >>> > args1 = defaultArguments() >>> > startListening(args1) // bound port updated >>> > startListening(args1) // already listening >>> > >>> > >>> > On 9/20/18 10:59 PM, Daniil Titov wrote: >>> >> Please review the change that fixes the issue in >>> com.sun.tools.jdi.SocketListenerConnector.startListening() method. >>> >> >>> >> When the argument map passed to startListening() methods has >>> the port number unspecified or set to zero the port is auto detected. >>> However, the consequent call of startListening() methods with >>> unspecified port number fails rather than starts a new listener on >>> auto detected port. This happens since the original argument map >>> passed to the startListening() methods is used as a key to store the >>> mapping to the started listeners. >>> >> >>> >> The fix ensures that in cases when the port is auto detected >>> the argument map is updated with the bound port number. >>> >> >>> >> Mach5 vmTestbase_nsk_jdi tests successfully passed. >>> >> >>> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> > >>> >>> >>> >> -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 27 18:58:07 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Sep 2018 11:58:07 -0700 Subject: RFR 8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <350E9BBD-1F19-46F6-A91E-AEAA1D0466D7@oracle.com> References: <413E8469-4880-488E-A23A-C4A2EB7F79E9@oracle.com> <61f16d11-3b9d-df5e-addc-068008e5c745@oracle.com> <5BA9215A.20209@oracle.com> <0b4d4fe2-48db-1e18-cfd3-c18a548e3973@oracle.com> <980b9582-400b-3caa-422f-4c4a1b97ac35@oracle.com> <7951F7C7-E586-4A06-98B1-4B3973DF9AE4@oracle.com> <3ED2E5D2-2215-4DE8-B368-3C4B9BDA48F8@oracle.com> <923cc71c-4941-efa3-4ec4-6185043b6a2a@oracle.com> <350E9BBD-1F19-46F6-A91E-AEAA1D0466D7@oracle.com> Message-ID: It looks good to me. Thanks! Serguei On 9/27/18 11:50 AM, Daniil Titov wrote: > > Hi Serguei, > > The webrev was updated to address all these comments. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.08 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > > --Daniil > > *From: * > *Organization: *Oracle Corporation > *Date: *Thursday, September 27, 2018 at 11:33 AM > *To: *Daniil Titov , JC Beyler > > *Cc: *, , > > *Subject: *Re: RFR 8163083: SocketListeningConnector does not allow > invocations with port 0 > > Just noticed one more minor issue: > > +import java.util.Collection; > +import java.util.Iterator; > +import java.util.LinkedHashMap; > > > ?It seems the above imports are not really used and can be removed. > > Thanks, > Serguei > > On 9/27/18 11:22 AM, serguei.spitsyn at oracle.com > wrote: > > Hi Daniil, > > It looks great, thank you for the update. > I have a couple of more minor comments on the test. > > ? 56???????? testWithDefaultArgs(connector); > > ? 57???????? testWithDefaultArgs2(connector); > > ? 58???????? testWithWildcardPort1(connector); > > ? 59???????? testWithWildcardPort2(connector); > > > ? Please, rename testWithDefaultArgs to testWithDefaultArgs1 > ? to make naming consistent. > > 111???????????? throw new RuntimeException("Test testWithDefaultArgsNegative failed. The argument map was not updated with" + > > 112???????????????????? " the bound port number."); > > 115???????????? // This call should fail since the previous the argument map is already updated with the port > > ?116???????????? // number of the started listener > > > ? Could you, please, re-balance the above line pairs to make the > first line shorter? > > No need in new webrev if you fix the above. > > Thanks, > Serguei > > On 9/27/18 11:00 AM, Daniil Titov wrote: > > Hi Serguei, > > Thank you for reviewing this change. Initially I understood > the whole fragment below? (from the Javadoc for > com.sun.jdi.connect.ListeningConnector.startListening() > method) as a direction for the user how to obtain and prepare > the argument map before passing it in startListening() method. > > ? 61????? * The argument map associates argument name strings to instances > > ? 62????? * of {@link Connector.Argument}. The default argument map for a > > ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. > > ? 64????? * Argument map values can be changed, but map entries should not be > > ? 65????? * added or deleted. > > But I agree that the last sentence could also mean that the > argument map values could be changes as a result of the method > invocation and in this case the new fragment in the Javadoc is > not needed. > > Please review the updated webrev that does not add new Javadoc > fragment and includes other changes you suggested. > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.07/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > > --Daniil > > *From: * > > *Organization: *Oracle Corporation > *Date: *Wednesday, September 26, 2018 at 8:12 PM > *To: *Daniil Titov > , JC Beyler > > *Cc: * > , > , > > > *Subject: *Re: RFR 8163083: SocketListeningConnector does not > allow invocations with port 0 > > Hi Daniil, > > It is great that you came up the fix for this issue. > Thanks to Gary for the help too. > > I wonder if we could get away without updating the javadoc > of com/sun/jdi/connect/ListeningConnector.java. > Filing a CSR would not be needed then (simple javadoc > reformatting should not require a CSR). > > So, my question is if this new fragment is really needed: > > ? 76????? *

> > ? 77????? * If the addressing information provided in {@code > arguments} implies > > ? 78????? * the auto detection this information might be > updated with the address > > ? 79????? * of the started listener. > > The javadoc for startListening already has this fragment: > > ? 61????? * The argument map associates argument name strings to instances > > ? 62????? * of {@link Connector.Argument}. The default argument map for a > > ? 63????? * connector can be obtained through {@link Connector#defaultArguments}. > > ? 64????? * Argument map values can be changed, but map entries should not be > > ? 65????? * added or deleted. > > > > that allows to change the argument map values. > > It looks like, it has to be Okay to add the bound port number there. > > > > Please, let me know what you think. > > Some formatting comments to addition to Jc's comments: > > ? 77????? * If the addressing information provided in {@code > arguments} implies > > ? 78????? * the auto detection this information might be > updated with the address > > ? 79????? * of the started listener. > > > > ? This sentence needs to be split in two: > > > > ? 77????? * If the addressing information provided in {@code > arguments} implies > > ? 78????? * the auto detection. This information might be > updated with the address > > ? 79????? * of the started listener. > > + > > +??? protected void updateArgumentMapIfRequired( > > +??????????? Map > args,TransportService.ListenKey listener) { > > +??? } > > + > > ? The indent has to be 4, not 8. > > +??????? if(isWildcardPort(args)) { > > +??????????? String[] address = listener.address().split(":"); > > +??????????? if (address.length > 1) { > > +??????????????? args.get(ARG_PORT).setValue(address[1]); > > +??????????? } > > +??????? } > > ? A space is missed after the first 'if'. > > ? 50???????????????????????? filter(c -> > > ? 51????????????? ???????????????????c.name().equals("com.sun.jdi.SocketListen")).findFirst().get(); > > ? This is better to be one liner. > > ? 57???????? testWithDefaultArgs(connector); > > ? 58???????? testWithDefaultArgs2(connector); > > ? 59???????? testWithWildcardPort(connector); > > ? 60???????? testWithWildcardPort2(connector); > > > > ? A suggestion is to rename above as below to have the names more unified: > > > > ? 57???????? testWithDefaultArgs1(connector); > > ? 58???????? testWithDefaultArgs2(connector); > > ? 59???????? testWithWildcardPort1(connector); > > ? 60???????? testWithWildcardPort2(connector); > > > > Thanks, > Serguei > > > On 9/25/18 10:32 AM, Daniil Titov wrote: > > HI JC, > > The webrev is updated to address this. > > Webrev: > http://cr.openjdk.java.net/~dtitov/8163083/webrev.06 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > *From: *JC Beyler > > *Date: *Monday, September 24, 2018 at 8:47 PM > *To: * > > *Cc: * > , > , > > > *Subject: *Re: RFR 8163083: SocketListeningConnector does > not allow invocations with port 0 > > Hi Daniil, > > Still looks good to me :) > > Nit: empty line 83 of the new test is not required! > > Jc > > On Mon, Sep 24, 2018 at 5:54 PM Daniil Titov > > wrote: > > Hi Alex, > > Please review the updated webrev that has new test > moved to test/jdk/comsun/jdi/connect folder. > > Webrev: > http://cr.openjdk.java.net/~dtitov/8163083/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 > > Thanks! > --Daniil > > > ?On 9/24/18, 2:56 PM, "Alex Menkov" > > wrote: > > ? ? Daniil, > > ? ? Just remembered that SQE requested to not add new > tests to vmTestbase > ? ? (see test/hotspot/jtreg/vmTestbase/README.md) > ? ? Could you please move the test to correct location > (I suppose it's > ? ? test/jdk/com/sun/jdi) > > ? ? --alex > > > ? ? On 09/24/2018 14:30, Alex Menkov wrote: > ? ? > +1 > ? ? > > ? ? > --alex > ? ? > > ? ? > On 09/24/2018 10:39, Gary Adams wrote: > ? ? >> Looks good to me. > ? ? >> > ? ? >> On 9/24/18, 1:25 PM, Daniil Titov wrote: > ? ? >>> Hi Alex and Gary, > ? ? >>> > ? ? >>> Please review the updated patch that includes > suggested changes. > ? ? >>> > ? ? >>> > http://cr.openjdk.java.net/~dtitov/8163083/webrev.04/ > > ? ? >>> Bug: > https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>> > ? ? >>> Thanks! > ? ? >>> --Daniil > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >>> ?On 9/21/18, 3:59 PM, "Alex > Menkov" > wrote: > ? ? >>> > ? ? >>>? ? ? One more note: > ? ? >>>? ? ? please add "@Override" annotation to the > ? ? >>> > SocketListeningConnector.updateArgumentMapIfRequired > ? ? >>> > ? ? >>>? ? ? --alex > ? ? >>> > ? ? >>>? ? ? On 09/21/2018 02:26, > gary.adams at oracle.com > wrote: > ? ? >>>? ? ? >? Looks good to me. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? For the javadoc > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?72? ? ? *

> ? ? >>>? ? ? >? ? ?73? ? ? * Ifarguments? > contains addressing > ? ? >>> information. and > ? ? >>>? ? ? >? ? ?74? ? ? * only one connection will > be accepted, the {@link > ? ? >>> #accept accept} method > ? ? >>>? ? ? >? ? ?75? ? ? * can be called immediately > without calling this > ? ? >>> method. > ? ? >>>? ? ? >? ? ?76? ? ? * > ? ? >>>? ? ? >? 77 * If the addressing information > provided > ? ? >>> inarguments > ? ? >>>? ? ? >? implies > ? ? >>>? ? ? >? 78 * the auto detection this > information might be updated > ? ? >>> with the address > ? ? >>>? ? ? >? 79 * of the started listener. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ?- you could add a

? tag if you > want to maintain the > ? ? >>> spacing in the > ? ? >>>? ? ? >? generated javadoc. > ? ? >>>? ? ? >? ? ?- I've seen other changesets > migrating to {@code ..} from > ? ? >>> the older > ? ? >>>? ? ? > ... > ? ? >>>? ? ? > > ? ? >>>? ? ? >? It would be good to include some > negative testing. > ? ? >>>? ? ? >? Not sure if it is already covered in > other tests, e.g. > ? ? >>>? ? ? > > ? ? >>>? ? ? >? ? ? ?args1 = defaultArguments() > ? ? >>>? ? ? > ?startListening(args1)? ?// bound port > updated > ? ? >>>? ? ? > ?startListening(args1)? ?// already > listening > ? ? >>>? ? ? > > ? ? >>>? ? ? > > ? ? >>>? ? ? >? On 9/20/18 10:59 PM, Daniil Titov wrote: > ? ? >>>? ? ? >>? Please review the change that fixes > the issue in > ? ? >>> > com.sun.tools.jdi.SocketListenerConnector.startListening() > method. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? When the argument map passed to > startListening() methods has > ? ? >>> the port number unspecified or set to zero the > port is auto detected. > ? ? >>> However,? the consequent call of > startListening() methods with > ? ? >>> unspecified port number fails rather than > starts a new listener on > ? ? >>> auto detected port. This happens since the > original argument map > ? ? >>> passed to the startListening() methods is used > as a key to store the > ? ? >>> mapping to the started listeners. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? The fix ensures that in cases when > the port is auto detected > ? ? >>> the argument map is updated with the bound > port number. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Mach5 vmTestbase_nsk_jdi tests > successfully passed. > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? > Bug:https://bugs.openjdk.java.net/browse/JDK-8163083 > ? ? >>>? ? ? >>? > Webrev:http://cr.openjdk.java.net/~dtitov/8163083/webrev.02/ > > ? ? >>>? ? ? >> > ? ? >>>? ? ? >>? Thanks! > ? ? >>>? ? ? >>? --Daniil > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? >> > ? ? >>>? ? ? > > ? ? >>> > ? ? >>> > ? ? >>> > ? ? >> > > > > > > -- > > Thanks, > > Jc > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Sep 27 19:12:12 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 27 Sep 2018 12:12:12 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <5BAD2509.7020407@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> Message-ID: <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> The extra check after timing out doesn't seem like it should help. You've already called findMessage() 2100 times at 200ms intervals. Why would one more call after that help? I think it might be the receiveReply() call that is fixing it. It does a waitForPrompt(), so this probably gives us another 420000 ms for the prompt to come in. This call to receiveReply() is actually a bug itself since we are doing it just to print the current buffer, not the buffer after waiting for a prompt to come in. In any case, looks like this prompt is taking more than 420200 milliseconds to come in, but does eventually come in, and extra waiting in receiveReply() is what is causing you to eventually see the prompt. I think bumping up the timeout to 600 and the waittime to 10 is the proper fix here. And to address the receiveReply() issue, I'd suggest calling it using receiveReply(startPos, false, 0), where 0 is the prompt count, and have receiveReply() not wait for a prompt when the count is 0. Chris On 9/27/18 11:44 AM, Gary Adams wrote: > Speaking of not being bullet proof, during testing of the fix to > wait for a specific prompt an intermittent failure was observed. > ... > > Sending command: trace methods 0x2a9 > reply[0]: MyThread-0[1] > Sending command: cont > WARNING: message not recieved: MyThread-0[1] > Remaining debugger output follows: > reply[0]:> > reply[1]: Method exited: return value =, > "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), > line=93 bci=14 > reply[2]: 93??????? } > reply[3]: > reply[4]: MyThread-0[1] > # ERROR: Caught unexpected exception while executing the test: > nsk.share.Failure: Expected message not received during 420200 > milliseconds: > ... > > The wait for message times out looking for "MyThread-0[1]". > A WARNING is printed and the "remaining debugger output" > shows that "MyThread-0[1]" is in the buffer. > > I'm still investigating why the message match is not found. > > Adding a final check before failing the wait for message > seems to workaround the problem. > > diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java > b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java > --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java > +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java > @@ -515,10 +515,11 @@ > ???????? long delta = 200; // time in milliseconds to wait at every > iteration. > ???????? long total = 0;??? // total time has waited. > ???????? long max = > getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; // > maximum time to wait. > +??????? int found = 0; > > ???????? Object dummy = new Object(); > ???????? while ((total += delta) <= max) { > -??????????? int found = 0; > +??????????? found = 0; > > ???????????? // search for message > ???????????? { > @@ -553,6 +554,12 @@ > ???????? log.display("WARNING: message not recieved: " + message); > ???????? log.display("Remaining debugger output follows:"); > ???????? receiveReply(startPos); > + > +??????? // One last chance > +??????? found = findMessage(startPos, message); > +??????? if (found > 0) { > +??????????? return found; > +??????? } > ???????? throw new Failure("Expected message not received during " + > total + " milliseconds:" > ???????????????????????????? + "\n\t" + message); > ???? } > > > On 9/20/18, 5:47 PM, Chris Plummer wrote: >> Looks good. Still not bullet proof, but I'm not sure it's possible to >> write tests like this in a way that will work no matter what output >> is produced by the method enter/exit events. >> >> Chris >> >> On 9/20/18 10:59 AM, Gary Adams wrote: >>> The test failure has been identified due to the "int[2]" >>> being misrecognized as a compound prompt.? This caused a cont >>> command to be sent prematurely. >>> >>> The proposed fix waits for the correct prompt before >>> advancing to the next command. >>> >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>> >>> Testing is in progress. >> >> >> > From alexey.menkov at oracle.com Thu Sep 27 21:32:42 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 27 Sep 2018 14:32:42 -0700 Subject: RFR JDK-8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java Message-ID: Hi all, please review a fix for https://bugs.openjdk.java.net/browse/JDK-8203928 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/non-jdb/webrev.01/ Some details: ImmutableResourceTest.java - required compile/run args are specified by using jtreg tag options; JITDebug.java - was not able to reproduce failures described (looks like that it's something ancient). Actually we use dt_socket transport on Windows for a long time without any issues; - replaced Runtime.exec with ProcessBuilder, used some /test/lib stuff, fixed some minor issues; connect/spi/JdiLoadedByCustomLoader.java redefine/RedefineTest.java redefineMethod/RedefineTest.java - implemented compilation tasks in java, removed shell files; PrivateTransportTest.java (was test/jdk/com/sun/jdi/PrivateTransportTest.sh) - just converted the test from shell to java. --alex From jcbeyler at google.com Thu Sep 27 21:33:06 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 27 Sep 2018 14:33:06 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> Message-ID: Hi all, Sorry to come back to this so late in the game, but somehow when I synced my hg clone (or the issue was always there and it is a flaky build), it seems that something in the build might have changed? Basically now it seems that the build is adding flags that makes my usage of unique_ptr fail. I "think" it is due to the build adding the gnu++98 standard (But this has been there for a while it seems so most likely a side-effect is it is being now used): CXXSTD_CXXFLAG="-std=gnu++98" FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG -Werror], IF_FALSE: [CXXSTD_CXXFLAG=""]) (from: https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4) but I'm not sure. When I remove that flag, my g++ goes to a more recent standard and unique_ptr works. So I now have to ask you all: 1) Should we try to fix the build system to at least have C++11 for the C++ tests, then my webrev.04 can stay as is but has to wait for that to happen 2) Should we push a new version that does not use unique_ptr? That solution would look like the following webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ Sorry for the last minute rug pull, Jc On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt wrote: > > Very, very nice! Thanks for adding the comment and renaming the class! > Ship it! > > Cheers, > Mikael > > > On Sep 27, 2018, at 10:45 AM, JC Beyler wrote: > > Hi Mikael and David, > > @David: I thought it was implicit but did not want to presume on this one > because my goal is to start propagating this new class in the test base and > get the checks to be done implicitly so I was probably being over-cautious > @Mikael: done and done, what do you think of the comment here : > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html > > For all, the new webrev is here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > > Thanks, > Jc > > On Thu, Sep 27, 2018 at 6:03 AM David Holmes > wrote: > >> Sorry Jc, I thought my LGTM was implicit. :) >> >> Thanks, >> David >> >> On 26/09/2018 11:52 PM, JC Beyler wrote: >> > Ping on this, anybody have time to do a review and give a LGTM? Or >> David >> > if you have time and will to provide an explicit LGTM :) >> > >> > Thanks, >> > Jc >> > >> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > > > wrote: >> > >> > Hi David, >> > >> > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting >> > for an explicit LGTM from you or from someone else on this list to >> > do a review. >> > >> > Thanks again for your help, >> > Jc >> > >> > On Sun, Sep 23, 2018 at 9:22 AM David Holmes >> > > wrote: >> > >> > Hi Jc, >> > >> > I don't think it is an issue for this to go ahead. If the static >> > analysis tool has an issue then we can either find out how to >> > teach it >> > about this code structure, or else flag the issues as false >> > positives. >> > I'd be relying on one of the serviceability team here to handle >> > that if >> > the problem arises. >> > >> > Thanks, >> > David >> > >> > On 23/09/2018 12:17 PM, JC Beyler wrote: >> > > Hi David, >> > > >> > > No worries with the time to answer; I appreciate the review! >> > > >> > > That's a fair point. Is it possible to "describe" to the >> > static analysis >> > > tool to "trust" calls made in the SafeJNIEnv class? >> > > >> > > Otherwise, do you have any idea on how to go forward? For >> > what it's >> > > worth, this current webrev does not try to replace exception >> > checking >> > > with the SafeJNIEnv (it actually adds it), so for now the >> > > question/solution could be delayed. I could continue working >> > on this in >> > > the scope of both the nsk/gc/lock/jniref code base and the >> > NSK_VERIFIER >> > > macro removal and we can look at how to tackle the cases >> > where the tests >> > > are actually calling exception checking (I know my >> > heapmonitor does for >> > > example). >> > > >> > > Let me know what you think and thanks for the review, >> > > Jc >> > > >> > > >> > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes >> > >> > > > > >> wrote: >> > > >> > > Hi Jc, >> > > >> > > Sorry for the delay on getting back to this but I'm >> > travelling at the >> > > moment. >> > > >> > > This looks quite neat. Thanks also to Alex for all the >> > suggestions. >> > > >> > > My only remaining concern is that static analysis tools >> > may not like >> > > this because they may not be able to determine that we >> > won't make >> > > subsequent JNI calls when an exception happens in the >> > first. That's not >> > > a reason not to do this of course, just flagging that we >> > may have to do >> > > something to deal with that problem. >> > > >> > > Thanks, >> > > David >> > > >> > > On 20/09/2018 11:56 AM, JC Beyler wrote: >> > > > Hi Alex, >> > > > >> > > > Done here, thanks for the review: >> > > > >> > > > Webrev: >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >> > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> >> > > > >> > >> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > >> > > > Thanks again! >> > > > Jc >> > > > >> > > > >> > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov >> > > > > >> > > alexey.menkov at oracle.com>> >> > > > > > >> > > > > >>> wrote: >> > > > >> > > > Hi Jc, >> > > > >> > > > Looks good to me. >> > > > A minor note: >> > > > - I'd move ErrorHandler typedef to SafeJNIEnv >> > class to avoid >> > > global >> > > > namespece pollution (ErrorHandler is too generic >> > name). >> > > > >> > > > --alex >> > > > >> > > > On 09/19/2018 15:56, JC Beyler wrote: >> > > > > Hi Alex, >> > > > > >> > > > > I've updated the webrev to: >> > > > > Webrev: >> > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >> > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> >> > > > >> > >> > > > > >> > >> > > > > Bug: >> > https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > > >> > > > > That webrev has the code that is shown here in >> > snippets. >> > > > > >> > > > > >> > > > > Thanks for the reviews, I've relatively >> > followed your reviews >> > > > except for >> > > > > one detail due to me wanting to handle the >> > NSK_JNI_VERIFY >> > > macros via >> > > > > this system as well later down the road. For an >> > example: >> > > > > >> > > > > We currently have in the code: >> > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >> > > NSK_CPP_STUB2(GetObjectClass, >> > > > > pEnv, mhToCall)) != NULL) ) >> > > > > >> > > > > 1) The NSK_CPP_STUB2 is trivially removed with >> > a refactor >> > > > (JDK-8210728) >> > > > > >> > to: >> > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >> > > pEnv->GetObjectClass(pEnv, >> > > > > mhToCall)) != NULL) ) >> > > > > >> > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove >> > it to and it >> > > > becomes via >> > > > > this wrapping of JNIEnv: >> > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, >> > mhToCall)) ) >> > > > > >> > > > > 3) Then, via removing the assignment, we'd >> > arrive to a: >> > > > > mhClass = pEnv->GetObjectClass(pEnv, >> mhToCall)); >> > > > > if (!mhClass) >> > > > > >> > > > > Without any loss of checking for failures, etc. >> > > > > >> > > > > So that is my motivation for most of this work >> > with a concrete >> > > > example >> > > > > (hopefully it helps drive this conversation). >> > > > > >> > > > > I inlined my answers here, let me know what you >> > think. >> > > > > >> > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov >> > > > > > >> > > alexey.menkov at oracle.com>> >> > > > > >> > > alexey.menkov at oracle.com>>> >> > > > > > > >> > > > > > >> > > > > > >> > > > > >>>> wrote: >> > > > > >> > > > > Hi Jc, >> > > > > >> > > > > Updated tests looks good. >> > > > > Some notes about implementation. >> > > > > >> > > > > - FatalOnException implements both >> > verification and error >> > > > handling >> > > > > It would be better to separate them (and >> > this makes >> > > easy to >> > > > implement >> > > > > error handling different from >> > JNIEnv::FatalError). >> > > > > The simplest way is to define error >> handler as >> > > > > class SafeJNIEnv { >> > > > > public: >> > > > > typedef void (*ErrorHandler)(JNIEnv >> > *env, const >> > > char* >> > > > errorMsg); >> > > > > // error handler which terminates jvm >> > by using >> > > FatalError() >> > > > > static void FatalError(JNIEnv *env, >> > const char >> > > *errrorMsg); >> > > > > >> > > > > SafeJNIEnv(JNIEnv* jni_env, >> ErrorHandler >> > > errorHandler = >> > > > > FatalError); >> > > > > (SafeJNIEnv methods should create >> > FatalOnException objects >> > > > passing >> > > > > errorHandler) >> > > > > >> > > > > >> > > > > >> > > > > Agreed, I tried to keep the code simple. The >> > concepts you >> > > talk about >> > > > > here are generally what I reserve for when I >> > need it (ie >> > > > extensions and >> > > > > handling new cases). But a lot are going to be >> > needed soon >> > > so I >> > > > think it >> > > > > is a good time to iron the code out now on this >> > "simple" >> > > webrev. >> > > > > >> > > > > So done for this. >> > > > > >> > > > > >> > > > > >> > > > > - FatalOnException is used in SafeJNIEnv >> > methods as >> > > > > FatalOnException marker(this, "msg"); >> > > > > ret = >> > > > > (optional)marker.check_for_null(ret); >> > > > > return ret; >> > > > > But actually I'd call it something like >> > > JNICallResultVerifier and >> > > > > create >> > > > > the object after JNI call. like >> > > > > ret = >> > > > > JNICallResultVerifier(this, "msg") >> > > > > (optional).notNull(ret); >> > > > > return ret; >> > > > > or even (if you like such syntax sugar) you >> > can define >> > > > > template >> > > > > T resultNotNull(T result) { >> > > > > notNull(result); >> > > > > return result; >> > > > > } >> > > > > and do >> > > > > ret = >> > > > > return JNICallResultVerifier(this, >> > > "msg").resultNotNull(ret); >> > > > > >> > > > > >> > > > > So I renamed FatalOnException to now being >> > JNIVerifier. >> > > > > >> > > > > Though I like it, I don't think we can do it, >> > except if we >> > > do it >> > > > > slightly differently: >> > > > > I'm trying to solve two problems with one >> stone: >> > > > > - How to check for returns of JNI calls in >> > the way that is >> > > > done here >> > > > > - How to remove NSK_JNI_VERIFY* (from >> > > nsk/share/jni/jni_tools) >> > > > > >> > > > > However, the NSK_JNI_VERIFY need to start a >> > tracing system >> > > before >> > > > the >> > > > > call to JNI, so it won't work this way. (Side >> > question >> > > would be >> > > > do we >> > > > > still care about the tracing in NSK_JNI_VERIFY, >> > if we >> > > don't then >> > > > your >> > > > > solution works well in most situations). >> > > > > >> > > > > My vision or intuition is that we would throw a >> > template >> > > at some >> > > > point >> > > > > on SafeJNIEnv to handle both cases and have >> > JNIVerifier >> > > become a >> > > > > specialization in certain cases and something >> > different >> > > for the >> > > > > NSK_JNI_VERIFY case (or have a different >> > constructor to enable >> > > > tracing). >> > > > > But for now, I offer the implementation that >> does: >> > > > > >> > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) >> { >> > > > > JNIVerifier marker(this, >> > "GetObjectClass"); >> > > > > return >> > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >> > > > > } >> > > > > >> > > > > and: >> > > > > >> > > > > void SafeJNIEnv::SetObjectField(jobject obj, >> > jfieldID >> > > field, jobject >> > > > > value) { >> > > > > JNIVerifier<> marker(this, >> "SetObjectField"); >> > > > > _jni_env->SetObjectField(obj, field, value); >> > > > > } >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > - you added #include in the test >> > (and you have to >> > > > add it to >> > > > > every test). >> > > > > It would be simpler to add the include to >> > > SafeJNIEnv.hpp and >> > > > define >> > > > > typedef std::unique_ptr >> > SafeJNIEnvPtr; >> > > > > Then each in the test methods: >> > > > > SafeJNIEnvPtr env(new >> SafeJNIEnv(jni_env)); >> > > > > or you can add >> > > > > static SafeJNIEnv::SafeJNIEnvPtr >> > wrap(JNIEnv* jni_env, >> > > > ErrorHandler >> > > > > errorHandler = fatalError) >> > > > > and get >> > > > > SafeJNIEnvPtr env = >> > SafeJNIEnv::wrap(jni_env); >> > > > > >> > > > > >> > > > > Done, I like that, even less code change to >> > tests then. >> > > > > >> > > > > >> > > > > >> > > > > - it would be better to wrap internal >> classes >> > > > (FatalOnException) into >> > > > > unnamed namespace - this helps to avoid >> > conflicts with >> > > other >> > > > classes) >> > > > > >> > > > > - FatalOnException::check_for_null(void* >> ptr) >> > > > > should be >> > > > > FatalOnException::check_for_null(const >> > void* ptr) >> > > > > And calling the method you don't need >> > reinterpret_cast >> > > > > >> > > > > >> > > > > Also done, it got renamed to ResultNotNull, is >> > using a >> > > template >> > > > now, but >> > > > > agreed, that worked. >> > > > > Thanks again for the review, >> > > > > Jc >> > > > > >> > > > > >> > > > > --alex >> > > > > >> > > > > >> > > > > On 09/18/2018 11:07, JC Beyler wrote: >> > > > > > Hi David, >> > > > > > >> > > > > > Thanks for the quick review and >> > thoughts. I have >> > > now a new >> > > > > version here >> > > > > > that addresses your comments: >> > > > > > >> > > > > > Webrev: >> > > > >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >> > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> >> > > > >> > >> > > > > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> >> > > > > > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> >> > > > > > >> > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > > > >> > > > > > I've also inlined my answers/comments. >> > > > > > >> > > > > > >> > > > > > >> > > > > > > I've slowly started working on >> > JDK-8191519 >> > > > > > > >> > > . >> > > > > However before >> > > > > > > starting to really refactor all >> > the tests, I >> > > > thought I'd >> > > > > get a few >> > > > > > > opinions. I am working on >> > internalizing the >> > > error >> > > > handling >> > > > > of JNI >> > > > > > calls >> > > > > > > via a SafeJNIEnv class that >> > redefines all >> > > the JNI >> > > > calls to >> > > > > add an >> > > > > > error >> > > > > > > checker. >> > > > > > > >> > > > > > > The advantage is that the test >> > code will >> > > look and >> > > > feel like >> > > > > > normal JNI >> > > > > > > code and calls but will have the >> > checks we >> > > want to have >> > > > > for our >> > > > > > tests. >> > > > > > >> > > > > > Not sure I get that. Normal JNI code >> > has to >> > > check for >> > > > > errors/exceptions >> > > > > > after every call. The tests need >> > those checks too. >> > > > Today they are >> > > > > > explicit, with this change they >> become >> > > implicit. Not sure >> > > > > what we are >> > > > > > gaining here ?? >> > > > > > >> > > > > > >> > > > > > In my humble opinion, having the error >> > checking out >> > > of the way >> > > > > allows >> > > > > > the code reader to concentrate on the >> > JNI code while >> > > > maintaining >> > > > > error >> > > > > > checking. We use something similar >> > internally, so >> > > perhaps I'm >> > > > > biased to >> > > > > > it :-). >> > > > > > If this is not a desired/helpful >> > "feature" to simplify >> > > > tests in >> > > > > general, >> > > > > > I will backtrack it and just add the >> > explicit tests >> > > to the >> > > > native >> > > > > code >> > > > > > of the locks for the fix >> > > > > > >> > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. >> > > > > > >> > > > > > Let me however try to make my case and >> > let me know what >> > > > you all >> > > > > think! >> > > > > > >> > > > > > >> > > > > > > If agreed with this, we can >> > augment the >> > > SafeJNIEnv >> > > > class >> > > > > as needed. >> > > > > > > Also, if the tests require >> > something else >> > > than fatal >> > > > > errors, we >> > > > > > can add >> > > > > > > a different marker and make it a >> > parameter >> > > to the >> > > > base class. >> > > > > > > >> > > > > > > Webrev: >> > > > > >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >> > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.00/> >> > > > >> > >> > > > > >> > > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.00/> >> > > > > > >> > > > >> > >> > > > > > > >> > > > >> > >> > > > > > > Bug: >> > > https://bugs.openjdk.java.net/browse/JDK-8210842 >> > > > > > > >> > > > > > > Let me know what you think, >> > > > > > >> > > > > > Two initial suggestions: >> > > > > > >> > > > > > 1. FatalOnException should be >> > constructed with a >> > > > description >> > > > > string so >> > > > > > that it can report the failing >> > operation when >> > > calling >> > > > > FatalError rather >> > > > > > than the general "Problem with a JNI >> > call". >> > > > > > >> > > > > > >> > > > > > Agreed with you, the new webrev >> produces: >> > > > > > >> > > > > > FATAL ERROR in native method: >> GetObjectClass >> > > > > > at >> > > > > >> > > > >> > > >> > >> nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >> > > > > > at >> > > > > >> > > >> > >> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >> > > > > Method) >> > > > > > at >> > > > > >> > > > >> > > >> > >> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >> > > > > > at >> > > > > >> > > > >> > > >> > >> nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >> > > > > > at >> > > > > >> > > java.lang.Thread.run(java.base at 12-internal >> /Thread.java:834) >> > > > > > >> > > > > > >> > > > > > and for a return NULL in NewGlobalRef, >> > we would get >> > > > automatically: >> > > > > > >> > > > > > FATAL ERROR in native method: >> > NewGlobalRef:Return >> > > is NULL >> > > > > > at >> > > > > >> > > >> > >> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >> > > > > Method) >> > > > > > >> > > > > > at >> > > > > > >> > > > > >> > > > >> > > >> > >> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Again as we port and simplify more tests >> > (I'll only >> > > do the >> > > > locks >> > > > > for now >> > > > > > and we can figure out the next steps as >> > start >> > > working on >> > > > moving >> > > > > tests >> > > > > > out of vmTestbase), >> > > > > > we can add, if needed, other exception >> > handlers >> > > that don't >> > > > throw >> > > > > or do >> > > > > > other things depending on the JNI method >> > outputs. >> > > > > > >> > > > > > >> > > > > > 2. Make the local SafeJNIEnv a >> > pointer called >> > > env so >> > > > that the >> > > > > change is >> > > > > > less disruptive. All the env->op() >> > calls will >> > > remain >> > > > and only >> > > > > the local >> > > > > > error checking will be removed. >> > > > > > >> > > > > > >> > > > > > Done, I used a unique_ptr to make the >> object >> > > > > created/destroyed/available >> > > > > > as a pointer do-able in one line: >> > > > > > std::unique_ptr env(new >> > > SafeJNIEnv(jni_env)); >> > > > > > >> > > > > > and then you can see that, as you >> > mentioned, the >> > > disruption to >> > > > > the code >> > > > > > is much less: >> > > > > > >> > > > > >> > > > >> > > >> > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > > >> > > > > > >> > > > > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> > >> > > > > > >> > > > > > Basically the tests now become internal >> > to the >> > > SafeJNIEnv >> > > > and the >> > > > > code >> > > > > > now only contains the JNI calls >> > happening but we >> > > are protected >> > > > > and will >> > > > > > fail any test that has an exception or a >> > NULL >> > > return for the >> > > > > call. Of >> > > > > > course, this is not 100% proof in terms >> > of not >> > > having any >> > > > error >> > > > > handling >> > > > > > in the test but in some cases like this, >> > the new >> > > code seems to >> > > > > just work >> > > > > > better: >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > > >> > > > > > >> > > > > >> > > > >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> > >> > > > > > >> > > > > > >> > > > > > >> > > > > > The switch from, e.g., checking NULL >> > returns to >> > > > checking for >> > > > > pending >> > > > > > exceptions, need to be sure that the >> > JNI operations >> > > > clearly >> > > > > specify >> > > > > > that >> > > > > > NULL implies there will be an >> exception >> > > pending. This >> > > > change >> > > > > may be an >> > > > > > issue for static code analysis if >> > not smart >> > > enough to >> > > > > understand the >> > > > > > RAII wrappers. >> > > > > > >> > > > > > >> > > > > > Agreed, I fixed it to be more strict and >> > say: in >> > > normal test >> > > > > handling, >> > > > > > the JNI calls should never return NULL >> > or throw an >> > > > exception. This >> > > > > > should hold for tests I imagine but if >> > not we can add a >> > > > different >> > > > > call >> > > > > > verifier as we go. >> > > > > > >> > > > > > >> > > > > > Thanks, >> > > > > > David >> > > > > > >> > > > > > > Jc >> > > > > > >> > > > > > >> > > > > > >> > > > > > Let me know what you all think. When >> > talking about it a >> > > > bit, I had >> > > > > > gotten some interest to see what it >> > would look >> > > like. Here >> > > > it is >> > > > > :-). Now >> > > > > > if it is not wanted like I said, I can >> > backtrack >> > > and just >> > > > put the >> > > > > error >> > > > > > checks after each JNI call for all the >> > tests as we are >> > > > porting them. >> > > > > > Jc >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > >> > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 27 22:43:34 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 27 Sep 2018 15:43:34 -0700 Subject: RFR JDK-8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java In-Reply-To: References: Message-ID: Hi Alex, Looks good to me, I especially liked the simplification of the PrivateTransportTest :) Jc On Thu, Sep 27, 2018 at 2:33 PM Alex Menkov wrote: > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8203928 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/non-jdb/webrev.01/ > > Some details: > > ImmutableResourceTest.java > - required compile/run args are specified by using jtreg tag options; > > JITDebug.java > - was not able to reproduce failures described (looks like that it's > something ancient). Actually we use dt_socket transport on Windows for a > long time without any issues; > - replaced Runtime.exec with ProcessBuilder, used some /test/lib > stuff, fixed some minor issues; > > connect/spi/JdiLoadedByCustomLoader.java > redefine/RedefineTest.java > redefineMethod/RedefineTest.java > - implemented compilation tasks in java, removed shell files; > > PrivateTransportTest.java (was > test/jdk/com/sun/jdi/PrivateTransportTest.sh) > - just converted the test from shell to java. > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Sep 28 01:23:30 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 27 Sep 2018 18:23:30 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> Message-ID: Some of us have lobbied to make openjdk source C++11, but it's not yet. If you're brave, you can try to change that flag to -std=gnu++11 On Thu, Sep 27, 2018 at 2:33 PM, JC Beyler wrote: > Hi all, > > Sorry to come back to this so late in the game, but somehow when I synced my > hg clone (or the issue was always there and it is a flaky build), it seems > that something in the build might have changed? Basically now it seems that > the build is adding flags that makes my usage of unique_ptr fail. > > I "think" it is due to the build adding the gnu++98 standard (But this has > been there for a while it seems so most likely a side-effect is it is being > now used): > > CXXSTD_CXXFLAG="-std=gnu++98" > FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG -Werror], > IF_FALSE: [CXXSTD_CXXFLAG=""]) > > (from: > https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4) > but I'm not sure. > > When I remove that flag, my g++ goes to a more recent standard and > unique_ptr works. > > So I now have to ask you all: > 1) Should we try to fix the build system to at least have C++11 for the > C++ tests, then my webrev.04 can stay as is but has to wait for that to > happen > 2) Should we push a new version that does not use unique_ptr? That > solution would look like the following webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ > > Sorry for the last minute rug pull, > Jc > > On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt > wrote: >> >> >> Very, very nice! Thanks for adding the comment and renaming the class! >> Ship it! >> >> Cheers, >> Mikael >> >> >> On Sep 27, 2018, at 10:45 AM, JC Beyler wrote: >> >> Hi Mikael and David, >> >> @David: I thought it was implicit but did not want to presume on this one >> because my goal is to start propagating this new class in the test base and >> get the checks to be done implicitly so I was probably being over-cautious >> @Mikael: done and done, what do you think of the comment here : >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html >> >> For all, the new webrev is here: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >> >> Thanks, >> Jc >> >> On Thu, Sep 27, 2018 at 6:03 AM David Holmes >> wrote: >>> >>> Sorry Jc, I thought my LGTM was implicit. :) >>> >>> Thanks, >>> David >>> >>> On 26/09/2018 11:52 PM, JC Beyler wrote: >>> > Ping on this, anybody have time to do a review and give a LGTM? Or >>> > David >>> > if you have time and will to provide an explicit LGTM :) >>> > >>> > Thanks, >>> > Jc >>> > >>> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler >> > > wrote: >>> > >>> > Hi David, >>> > >>> > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting >>> > for an explicit LGTM from you or from someone else on this list to >>> > do a review. >>> > >>> > Thanks again for your help, >>> > Jc >>> > >>> > On Sun, Sep 23, 2018 at 9:22 AM David Holmes >>> > > wrote: >>> > >>> > Hi Jc, >>> > >>> > I don't think it is an issue for this to go ahead. If the >>> > static >>> > analysis tool has an issue then we can either find out how to >>> > teach it >>> > about this code structure, or else flag the issues as false >>> > positives. >>> > I'd be relying on one of the serviceability team here to handle >>> > that if >>> > the problem arises. >>> > >>> > Thanks, >>> > David >>> > >>> > On 23/09/2018 12:17 PM, JC Beyler wrote: >>> > > Hi David, >>> > > >>> > > No worries with the time to answer; I appreciate the review! >>> > > >>> > > That's a fair point. Is it possible to "describe" to the >>> > static analysis >>> > > tool to "trust" calls made in the SafeJNIEnv class? >>> > > >>> > > Otherwise, do you have any idea on how to go forward? For >>> > what it's >>> > > worth, this current webrev does not try to replace exception >>> > checking >>> > > with the SafeJNIEnv (it actually adds it), so for now the >>> > > question/solution could be delayed. I could continue working >>> > on this in >>> > > the scope of both the nsk/gc/lock/jniref code base and the >>> > NSK_VERIFIER >>> > > macro removal and we can look at how to tackle the cases >>> > where the tests >>> > > are actually calling exception checking (I know my >>> > heapmonitor does for >>> > > example). >>> > > >>> > > Let me know what you think and thanks for the review, >>> > > Jc >>> > > >>> > > >>> > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes >>> > >>> > > >> > >> wrote: >>> > > >>> > > Hi Jc, >>> > > >>> > > Sorry for the delay on getting back to this but I'm >>> > travelling at the >>> > > moment. >>> > > >>> > > This looks quite neat. Thanks also to Alex for all the >>> > suggestions. >>> > > >>> > > My only remaining concern is that static analysis tools >>> > may not like >>> > > this because they may not be able to determine that we >>> > won't make >>> > > subsequent JNI calls when an exception happens in the >>> > first. That's not >>> > > a reason not to do this of course, just flagging that we >>> > may have to do >>> > > something to deal with that problem. >>> > > >>> > > Thanks, >>> > > David >>> > > >>> > > On 20/09/2018 11:56 AM, JC Beyler wrote: >>> > > > Hi Alex, >>> > > > >>> > > > Done here, thanks for the review: >>> > > > >>> > > > Webrev: >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >>> > >>> > > >>> > >>> > > > >>> > >>> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > >>> > > > Thanks again! >>> > > > Jc >>> > > > >>> > > > >>> > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov >>> > > >> > >>> > >> > > >>> > > > >> > >>> > > >> > >>> wrote: >>> > > > >>> > > > Hi Jc, >>> > > > >>> > > > Looks good to me. >>> > > > A minor note: >>> > > > - I'd move ErrorHandler typedef to SafeJNIEnv >>> > class to avoid >>> > > global >>> > > > namespece pollution (ErrorHandler is too generic >>> > name). >>> > > > >>> > > > --alex >>> > > > >>> > > > On 09/19/2018 15:56, JC Beyler wrote: >>> > > > > Hi Alex, >>> > > > > >>> > > > > I've updated the webrev to: >>> > > > > Webrev: >>> > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >>> > >>> > > >>> > >>> > > > >>> > >>> > > > > >>> > >>> > > > > Bug: >>> > https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > > >>> > > > > That webrev has the code that is shown here in >>> > snippets. >>> > > > > >>> > > > > >>> > > > > Thanks for the reviews, I've relatively >>> > followed your reviews >>> > > > except for >>> > > > > one detail due to me wanting to handle the >>> > NSK_JNI_VERIFY >>> > > macros via >>> > > > > this system as well later down the road. For >>> > an >>> > example: >>> > > > > >>> > > > > We currently have in the code: >>> > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >>> > > NSK_CPP_STUB2(GetObjectClass, >>> > > > > pEnv, mhToCall)) != NULL) ) >>> > > > > >>> > > > > 1) The NSK_CPP_STUB2 is trivially removed with >>> > a refactor >>> > > > (JDK-8210728) >>> > > > > >>> > to: >>> > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >>> > > pEnv->GetObjectClass(pEnv, >>> > > > > mhToCall)) != NULL) ) >>> > > > > >>> > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove >>> > it to and it >>> > > > becomes via >>> > > > > this wrapping of JNIEnv: >>> > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, >>> > mhToCall)) ) >>> > > > > >>> > > > > 3) Then, via removing the assignment, we'd >>> > arrive to a: >>> > > > > mhClass = pEnv->GetObjectClass(pEnv, >>> > mhToCall)); >>> > > > > if (!mhClass) >>> > > > > >>> > > > > Without any loss of checking for failures, >>> > etc. >>> > > > > >>> > > > > So that is my motivation for most of this work >>> > with a concrete >>> > > > example >>> > > > > (hopefully it helps drive this conversation). >>> > > > > >>> > > > > I inlined my answers here, let me know what >>> > you >>> > think. >>> > > > > >>> > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov >>> > > > >> > >>> > >> > > >>> > > >> > >>> > >> > >> >>> > > > > >> > >>> > > >> > > >>> > > > >> > >>> > > >> > >>>> wrote: >>> > > > > >>> > > > > Hi Jc, >>> > > > > >>> > > > > Updated tests looks good. >>> > > > > Some notes about implementation. >>> > > > > >>> > > > > - FatalOnException implements both >>> > verification and error >>> > > > handling >>> > > > > It would be better to separate them (and >>> > this makes >>> > > easy to >>> > > > implement >>> > > > > error handling different from >>> > JNIEnv::FatalError). >>> > > > > The simplest way is to define error >>> > handler as >>> > > > > class SafeJNIEnv { >>> > > > > public: >>> > > > > typedef void (*ErrorHandler)(JNIEnv >>> > *env, const >>> > > char* >>> > > > errorMsg); >>> > > > > // error handler which terminates >>> > jvm >>> > by using >>> > > FatalError() >>> > > > > static void FatalError(JNIEnv *env, >>> > const char >>> > > *errrorMsg); >>> > > > > >>> > > > > SafeJNIEnv(JNIEnv* jni_env, >>> > ErrorHandler >>> > > errorHandler = >>> > > > > FatalError); >>> > > > > (SafeJNIEnv methods should create >>> > FatalOnException objects >>> > > > passing >>> > > > > errorHandler) >>> > > > > >>> > > > > >>> > > > > >>> > > > > Agreed, I tried to keep the code simple. The >>> > concepts you >>> > > talk about >>> > > > > here are generally what I reserve for when I >>> > need it (ie >>> > > > extensions and >>> > > > > handling new cases). But a lot are going to be >>> > needed soon >>> > > so I >>> > > > think it >>> > > > > is a good time to iron the code out now on >>> > this >>> > "simple" >>> > > webrev. >>> > > > > >>> > > > > So done for this. >>> > > > > >>> > > > > >>> > > > > >>> > > > > - FatalOnException is used in SafeJNIEnv >>> > methods as >>> > > > > FatalOnException marker(this, "msg"); >>> > > > > ret = >>> > > > > (optional)marker.check_for_null(ret); >>> > > > > return ret; >>> > > > > But actually I'd call it something like >>> > > JNICallResultVerifier and >>> > > > > create >>> > > > > the object after JNI call. like >>> > > > > ret = >>> > > > > JNICallResultVerifier(this, "msg") >>> > > > > (optional).notNull(ret); >>> > > > > return ret; >>> > > > > or even (if you like such syntax sugar) >>> > you >>> > can define >>> > > > > template >>> > > > > T resultNotNull(T result) { >>> > > > > notNull(result); >>> > > > > return result; >>> > > > > } >>> > > > > and do >>> > > > > ret = >>> > > > > return JNICallResultVerifier(this, >>> > > "msg").resultNotNull(ret); >>> > > > > >>> > > > > >>> > > > > So I renamed FatalOnException to now being >>> > JNIVerifier. >>> > > > > >>> > > > > Though I like it, I don't think we can do it, >>> > except if we >>> > > do it >>> > > > > slightly differently: >>> > > > > I'm trying to solve two problems with one >>> > stone: >>> > > > > - How to check for returns of JNI calls in >>> > the way that is >>> > > > done here >>> > > > > - How to remove NSK_JNI_VERIFY* (from >>> > > nsk/share/jni/jni_tools) >>> > > > > >>> > > > > However, the NSK_JNI_VERIFY need to start a >>> > tracing system >>> > > before >>> > > > the >>> > > > > call to JNI, so it won't work this way. (Side >>> > question >>> > > would be >>> > > > do we >>> > > > > still care about the tracing in >>> > NSK_JNI_VERIFY, >>> > if we >>> > > don't then >>> > > > your >>> > > > > solution works well in most situations). >>> > > > > >>> > > > > My vision or intuition is that we would throw >>> > a >>> > template >>> > > at some >>> > > > point >>> > > > > on SafeJNIEnv to handle both cases and have >>> > JNIVerifier >>> > > become a >>> > > > > specialization in certain cases and something >>> > different >>> > > for the >>> > > > > NSK_JNI_VERIFY case (or have a different >>> > constructor to enable >>> > > > tracing). >>> > > > > But for now, I offer the implementation that >>> > does: >>> > > > > >>> > > > > jclass SafeJNIEnv::GetObjectClass(jobject obj) >>> > { >>> > > > > JNIVerifier marker(this, >>> > "GetObjectClass"); >>> > > > > return >>> > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >>> > > > > } >>> > > > > >>> > > > > and: >>> > > > > >>> > > > > void SafeJNIEnv::SetObjectField(jobject obj, >>> > jfieldID >>> > > field, jobject >>> > > > > value) { >>> > > > > JNIVerifier<> marker(this, >>> > "SetObjectField"); >>> > > > > _jni_env->SetObjectField(obj, field, >>> > value); >>> > > > > } >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > - you added #include in the test >>> > (and you have to >>> > > > add it to >>> > > > > every test). >>> > > > > It would be simpler to add the include to >>> > > SafeJNIEnv.hpp and >>> > > > define >>> > > > > typedef std::unique_ptr >>> > SafeJNIEnvPtr; >>> > > > > Then each in the test methods: >>> > > > > SafeJNIEnvPtr env(new >>> > SafeJNIEnv(jni_env)); >>> > > > > or you can add >>> > > > > static SafeJNIEnv::SafeJNIEnvPtr >>> > wrap(JNIEnv* jni_env, >>> > > > ErrorHandler >>> > > > > errorHandler = fatalError) >>> > > > > and get >>> > > > > SafeJNIEnvPtr env = >>> > SafeJNIEnv::wrap(jni_env); >>> > > > > >>> > > > > >>> > > > > Done, I like that, even less code change to >>> > tests then. >>> > > > > >>> > > > > >>> > > > > >>> > > > > - it would be better to wrap internal >>> > classes >>> > > > (FatalOnException) into >>> > > > > unnamed namespace - this helps to avoid >>> > conflicts with >>> > > other >>> > > > classes) >>> > > > > >>> > > > > - FatalOnException::check_for_null(void* >>> > ptr) >>> > > > > should be >>> > > > > FatalOnException::check_for_null(const >>> > void* ptr) >>> > > > > And calling the method you don't need >>> > reinterpret_cast >>> > > > > >>> > > > > >>> > > > > Also done, it got renamed to ResultNotNull, is >>> > using a >>> > > template >>> > > > now, but >>> > > > > agreed, that worked. >>> > > > > Thanks again for the review, >>> > > > > Jc >>> > > > > >>> > > > > >>> > > > > --alex >>> > > > > >>> > > > > >>> > > > > On 09/18/2018 11:07, JC Beyler wrote: >>> > > > > > Hi David, >>> > > > > > >>> > > > > > Thanks for the quick review and >>> > thoughts. I have >>> > > now a new >>> > > > > version here >>> > > > > > that addresses your comments: >>> > > > > > >>> > > > > > Webrev: >>> > > > >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >>> > >>> > > >>> > >>> > > > >>> > >>> > > > > >>> > > >>> > >>> > > > > > >>> > > >>> > >>> > > > > > >>> > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > > > >>> > > > > > I've also inlined my answers/comments. >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > I've slowly started working on >>> > JDK-8191519 >>> > > > > > > >>> > > . >>> > > > > However before >>> > > > > > > starting to really refactor all >>> > the tests, I >>> > > > thought I'd >>> > > > > get a few >>> > > > > > > opinions. I am working on >>> > internalizing the >>> > > error >>> > > > handling >>> > > > > of JNI >>> > > > > > calls >>> > > > > > > via a SafeJNIEnv class that >>> > redefines all >>> > > the JNI >>> > > > calls to >>> > > > > add an >>> > > > > > error >>> > > > > > > checker. >>> > > > > > > >>> > > > > > > The advantage is that the test >>> > code will >>> > > look and >>> > > > feel like >>> > > > > > normal JNI >>> > > > > > > code and calls but will have the >>> > checks we >>> > > want to have >>> > > > > for our >>> > > > > > tests. >>> > > > > > >>> > > > > > Not sure I get that. Normal JNI >>> > code >>> > has to >>> > > check for >>> > > > > errors/exceptions >>> > > > > > after every call. The tests need >>> > those checks too. >>> > > > Today they are >>> > > > > > explicit, with this change they >>> > become >>> > > implicit. Not sure >>> > > > > what we are >>> > > > > > gaining here ?? >>> > > > > > >>> > > > > > >>> > > > > > In my humble opinion, having the error >>> > checking out >>> > > of the way >>> > > > > allows >>> > > > > > the code reader to concentrate on the >>> > JNI code while >>> > > > maintaining >>> > > > > error >>> > > > > > checking. We use something similar >>> > internally, so >>> > > perhaps I'm >>> > > > > biased to >>> > > > > > it :-). >>> > > > > > If this is not a desired/helpful >>> > "feature" to simplify >>> > > > tests in >>> > > > > general, >>> > > > > > I will backtrack it and just add the >>> > explicit tests >>> > > to the >>> > > > native >>> > > > > code >>> > > > > > of the locks for the fix >>> > > > > > >>> > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. >>> > > > > > >>> > > > > > Let me however try to make my case and >>> > let me know what >>> > > > you all >>> > > > > think! >>> > > > > > >>> > > > > > >>> > > > > > > If agreed with this, we can >>> > augment the >>> > > SafeJNIEnv >>> > > > class >>> > > > > as needed. >>> > > > > > > Also, if the tests require >>> > something else >>> > > than fatal >>> > > > > errors, we >>> > > > > > can add >>> > > > > > > a different marker and make it a >>> > parameter >>> > > to the >>> > > > base class. >>> > > > > > > >>> > > > > > > Webrev: >>> > > > > >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >>> > >>> > > >>> > >>> > > > >>> > >>> > > > > >>> > > >>> > >>> > > > > > >>> > > > >>> > >>> > > > > > > >>> > > > >>> > >>> > > > > > > Bug: >>> > > https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > > > > >>> > > > > > > Let me know what you think, >>> > > > > > >>> > > > > > Two initial suggestions: >>> > > > > > >>> > > > > > 1. FatalOnException should be >>> > constructed with a >>> > > > description >>> > > > > string so >>> > > > > > that it can report the failing >>> > operation when >>> > > calling >>> > > > > FatalError rather >>> > > > > > than the general "Problem with a >>> > JNI >>> > call". >>> > > > > > >>> > > > > > >>> > > > > > Agreed with you, the new webrev >>> > produces: >>> > > > > > >>> > > > > > FATAL ERROR in native method: >>> > GetObjectClass >>> > > > > > at >>> > > > > >>> > > > >>> > > >>> > >>> > nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >>> > > > > > at >>> > > > > >>> > > >>> > >>> > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>> > > > > Method) >>> > > > > > at >>> > > > > >>> > > > >>> > > >>> > >>> > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>> > > > > > at >>> > > > > >>> > > > >>> > > >>> > >>> > nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >>> > > > > > at >>> > > > > >>> > > >>> > java.lang.Thread.run(java.base at 12-internal/Thread.java:834) >>> > > > > > >>> > > > > > >>> > > > > > and for a return NULL in NewGlobalRef, >>> > we would get >>> > > > automatically: >>> > > > > > >>> > > > > > FATAL ERROR in native method: >>> > NewGlobalRef:Return >>> > > is NULL >>> > > > > > at >>> > > > > >>> > > >>> > >>> > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>> > > > > Method) >>> > > > > > >>> > > > > > at >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> > nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>> > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > Again as we port and simplify more >>> > tests >>> > (I'll only >>> > > do the >>> > > > locks >>> > > > > for now >>> > > > > > and we can figure out the next steps as >>> > start >>> > > working on >>> > > > moving >>> > > > > tests >>> > > > > > out of vmTestbase), >>> > > > > > we can add, if needed, other exception >>> > handlers >>> > > that don't >>> > > > throw >>> > > > > or do >>> > > > > > other things depending on the JNI >>> > method >>> > outputs. >>> > > > > > >>> > > > > > >>> > > > > > 2. Make the local SafeJNIEnv a >>> > pointer called >>> > > env so >>> > > > that the >>> > > > > change is >>> > > > > > less disruptive. All the env->op() >>> > calls will >>> > > remain >>> > > > and only >>> > > > > the local >>> > > > > > error checking will be removed. >>> > > > > > >>> > > > > > >>> > > > > > Done, I used a unique_ptr to make the >>> > object >>> > > > > created/destroyed/available >>> > > > > > as a pointer do-able in one line: >>> > > > > > std::unique_ptr env(new >>> > > SafeJNIEnv(jni_env)); >>> > > > > > >>> > > > > > and then you can see that, as you >>> > mentioned, the >>> > > disruption to >>> > > > > the code >>> > > > > > is much less: >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > >>> > >>> > > >>> > >>> > >>> > > > >>> > > >>> > >>> > >>> > > > > >>> > > > >>> > > >>> > >>> > >>> > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> > >>> > > > > > >>> > > > > > Basically the tests now become internal >>> > to the >>> > > SafeJNIEnv >>> > > > and the >>> > > > > code >>> > > > > > now only contains the JNI calls >>> > happening but we >>> > > are protected >>> > > > > and will >>> > > > > > fail any test that has an exception or >>> > a >>> > NULL >>> > > return for the >>> > > > > call. Of >>> > > > > > course, this is not 100% proof in terms >>> > of not >>> > > having any >>> > > > error >>> > > > > handling >>> > > > > > in the test but in some cases like >>> > this, >>> > the new >>> > > code seems to >>> > > > > just work >>> > > > > > better: >>> > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > >>> > >>> > > >>> > >>> > >>> > > > >>> > > >>> > >>> > >>> > > > > >>> > > > >>> > > >>> > >>> > >>> > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > The switch from, e.g., checking >>> > NULL >>> > returns to >>> > > > checking for >>> > > > > pending >>> > > > > > exceptions, need to be sure that >>> > the >>> > JNI operations >>> > > > clearly >>> > > > > specify >>> > > > > > that >>> > > > > > NULL implies there will be an >>> > exception >>> > > pending. This >>> > > > change >>> > > > > may be an >>> > > > > > issue for static code analysis if >>> > not smart >>> > > enough to >>> > > > > understand the >>> > > > > > RAII wrappers. >>> > > > > > >>> > > > > > >>> > > > > > Agreed, I fixed it to be more strict >>> > and >>> > say: in >>> > > normal test >>> > > > > handling, >>> > > > > > the JNI calls should never return NULL >>> > or throw an >>> > > > exception. This >>> > > > > > should hold for tests I imagine but if >>> > not we can add a >>> > > > different >>> > > > > call >>> > > > > > verifier as we go. >>> > > > > > >>> > > > > > >>> > > > > > Thanks, >>> > > > > > David >>> > > > > > >>> > > > > > > Jc >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > Let me know what you all think. When >>> > talking about it a >>> > > > bit, I had >>> > > > > > gotten some interest to see what it >>> > would look >>> > > like. Here >>> > > > it is >>> > > > > :-). Now >>> > > > > > if it is not wanted like I said, I can >>> > backtrack >>> > > and just >>> > > > put the >>> > > > > error >>> > > > > > checks after each JNI call for all the >>> > tests as we are >>> > > > porting them. >>> > > > > > Jc >>> > > > > >>> > > > > >>> > > > > >>> > > > > -- >>> > > > > >>> > > > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Fri Sep 28 03:00:47 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Sep 2018 20:00:47 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> Message-ID: <05f50598-a193-908e-c645-17955b2dc451@oracle.com> Hi Jc, Sorry for being late to the party. The webrev5 looks good to me. I don't think you have to try to fix the build system. Avoiding using unique_ptr is good enough. Do I understand it right that the ExceptionCheckingJniEnv class is going to enhanced with more JNI functions? I'm wonder if it can be anyhow generalized to avoid this. Thanks, Serguei ** On 9/27/18 2:33 PM, JC Beyler wrote: > Hi all, > > Sorry to come back to this so late in the game, but somehow when I > synced my hg clone (or the issue was always there and it is a flaky > build), it seems that something in the build might have changed? > Basically now it seems that the build is adding flags that makes my > usage of unique_ptr fail. > > I "think" it is due to the build adding the gnu++98 standard (But this > has been there for a while it seems so most likely a side-effect is it > is being now used): > > ? ? CXXSTD_CXXFLAG="-std=gnu++98" > ? ? FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG > -Werror], > IF_FALSE: [CXXSTD_CXXFLAG=""]) > > (from: > https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4) > but I'm not sure. > > When I remove that flag, my g++ goes to a more recent standard and > unique_ptr works. > > So I now have to ask you all: > ? 1) Should we try to fix the build system to at least have C++11 for > the C++ tests, then my webrev.04 can stay as is but has to wait for > that to happen > ? 2) Should we push a new version that does not use unique_ptr? That > solution would look like the following webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ > > > Sorry for the last minute rug pull, > Jc > > On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt > > wrote: > > > Very, very nice! Thanks for adding the comment and renaming the > class! Ship it! > > Cheers, > Mikael > > >> On Sep 27, 2018, at 10:45 AM, JC Beyler > > wrote: >> >> Hi Mikael and David, >> >> @David: I thought it was implicit but did not want to presume on >> this one because my goal is to start propagating this new class >> in the test base and get the checks to be done implicitly so I >> was probably being over-cautious >> @Mikael: done and done, what do you think of the comment here : >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html >> >> >> For all, the new webrev is here: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >> >> Thanks, >> Jc >> >> On Thu, Sep 27, 2018 at 6:03 AM David Holmes >> > wrote: >> >> Sorry Jc, I thought my LGTM was implicit. :) >> >> Thanks, >> David >> >> On 26/09/2018 11:52 PM, JC Beyler wrote: >> > Ping on this, anybody have time to do a review and give a >> LGTM? Or David >> > if you have time and will to provide an explicit LGTM :) >> > >> > Thanks, >> > Jc >> > >> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler >> >> > >> >> wrote: >> > >> >? ? ?Hi David, >> > >> >? ? ?Sounds good to me, Alex gave me one LGTM, so it seems >> I'm waiting >> >? ? ?for an explicit LGTM from you or from someone else on >> this list to >> >? ? ?do a review. >> > >> >? ? ?Thanks again for your help, >> >? ? ?Jc >> > >> >? ? ?On Sun, Sep 23, 2018 at 9:22 AM David Holmes >> >? ? ?> >> > >> wrote: >> > >> >? ? ? ? ?Hi Jc, >> > >> >? ? ? ? ?I don't think it is an issue for this to go ahead. >> If the static >> >? ? ? ? ?analysis tool has an issue then we can either find >> out how to >> >? ? ? ? ?teach it >> >? ? ? ? ?about this code structure, or else flag the issues >> as false >> >? ? ? ? ?positives. >> >? ? ? ? ?I'd be relying on one of the serviceability team >> here to handle >> >? ? ? ? ?that if >> >? ? ? ? ?the problem arises. >> > >> >? ? ? ? ?Thanks, >> >? ? ? ? ?David >> > >> >? ? ? ? ?On 23/09/2018 12:17 PM, JC Beyler wrote: >> >? ? ? ? ? > Hi David, >> >? ? ? ? ? > >> >? ? ? ? ? > No worries with the time to answer; I appreciate >> the review! >> >? ? ? ? ? > >> >? ? ? ? ? > That's a fair point. Is it possible to >> "describe" to the >> >? ? ? ? ?static analysis >> >? ? ? ? ? > tool to "trust" calls made in the SafeJNIEnv class? >> >? ? ? ? ? > >> >? ? ? ? ? > Otherwise, do you have any idea on how to go >> forward? For >> >? ? ? ? ?what it's >> >? ? ? ? ? > worth, this current webrev does not try to >> replace exception >> >? ? ? ? ?checking >> >? ? ? ? ? > with the SafeJNIEnv (it actually adds it), so >> for now the >> >? ? ? ? ? > question/solution could be delayed. I could >> continue working >> >? ? ? ? ?on this in >> >? ? ? ? ? > the scope of both the nsk/gc/lock/jniref code >> base and the >> >? ? ? ? ?NSK_VERIFIER >> >? ? ? ? ? > macro removal and we can look at how to tackle >> the cases >> >? ? ? ? ?where the tests >> >? ? ? ? ? > are actually calling exception checking (I know my >> >? ? ? ? ?heapmonitor does for >> >? ? ? ? ? > example). >> >? ? ? ? ? > >> >? ? ? ? ? > Let me know what you think and thanks for the >> review, >> >? ? ? ? ? > Jc >> >? ? ? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? > On Sun, Sep 23, 2018 at 6:48 AM David Holmes >> >? ? ? ? ?> >> > >> >? ? ? ? ? > > >> >? ? ? ? ?> >>> wrote: >> >? ? ? ? ? > >> >? ? ? ? ? >? ? ?Hi Jc, >> >? ? ? ? ? > >> >? ? ? ? ? >? ? ?Sorry for the delay on getting back to this >> but I'm >> >? ? ? ? ?travelling at the >> >? ? ? ? ? >? ? ?moment. >> >? ? ? ? ? > >> >? ? ? ? ? >? ? ?This looks quite neat. Thanks also to Alex >> for all the >> >? ? ? ? ?suggestions. >> >? ? ? ? ? > >> >? ? ? ? ? >? ? ?My only remaining concern is that static >> analysis tools >> >? ? ? ? ?may not like >> >? ? ? ? ? >? ? ?this because they may not be able to >> determine that we >> >? ? ? ? ?won't make >> >? ? ? ? ? >? ? ?subsequent JNI calls when an exception >> happens in the >> >? ? ? ? ?first. That's not >> >? ? ? ? ? >? ? ?a reason not to do this of course, just >> flagging that we >> >? ? ? ? ?may have to do >> >? ? ? ? ? >? ? ?something to deal with that problem. >> >? ? ? ? ? > >> >? ? ? ? ? >? ? ?Thanks, >> >? ? ? ? ? >? ? ?David >> >? ? ? ? ? > >> >? ? ? ? ? >? ? ?On 20/09/2018 11:56 AM, JC Beyler wrote: >> >? ? ? ? ? >? ? ? > Hi Alex, >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > Done here, thanks for the review: >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > Webrev: >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >> >> >? ? ? ? >> ? >> >? ? ? ? ? >? ? >> ? >> >? ? ? ? ? >? ? ? > >> >? ? ? ? >> ? >> >? ? ? ? ? >? ? ? > Bug: >> https://bugs.openjdk.java.net/browse/JDK-8210842 >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > Thanks again! >> >? ? ? ? ? >? ? ? > Jc >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov >> >? ? ? ? ? >? ? ?> >> >? ? ? ? ?> > >> >? ? ? ? ?> >> > >> >> >? ? ? ? ? >? ? ? > > >> >? ? ? ? ?> > >> >? ? ? ? ? >? ? ?> >> >? ? ? ? ?> >>>> wrote: >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ?Hi Jc, >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ?Looks good to me. >> >? ? ? ? ? >? ? ? >? ? ?A minor note: >> >? ? ? ? ? >? ? ? >? ? ?- I'd move ErrorHandler typedef to >> SafeJNIEnv >> >? ? ? ? ?class to avoid >> >? ? ? ? ? >? ? ?global >> >? ? ? ? ? >? ? ? >? ? ?namespece pollution (ErrorHandler is >> too generic >> >? ? ? ? ?name). >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ?--alex >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ?On 09/19/2018 15:56, JC Beyler wrote: >> >? ? ? ? ? >? ? ? >? ? ? > Hi Alex, >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > I've updated the webrev to: >> >? ? ? ? ? >? ? ? >? ? ? > Webrev: >> >? ? ? ? ? > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >> >> >? ? ? ? >> ? >> >? ? ? ? ? >? ? >> ? >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > Bug: >> > https://bugs.openjdk.java.net/browse/JDK-8210842 >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > That webrev has the code that is >> shown here in >> >? ? ? ? ?snippets. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > Thanks for the reviews, I've >> relatively >> >? ? ? ? ?followed your reviews >> >? ? ? ? ? >? ? ? >? ? ?except for >> >? ? ? ? ? >? ? ? >? ? ? > one detail due to me wanting to >> handle the >> >? ? ? ? ?NSK_JNI_VERIFY >> >? ? ? ? ? >? ? ?macros via >> >? ? ? ? ? >? ? ? >? ? ? > this system as well later down the >> road. For an >> >? ? ? ? ?example: >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > We currently have in the code: >> >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >> >? ? ? ? ? > ?NSK_CPP_STUB2(GetObjectClass, >> >? ? ? ? ? >? ? ? >? ? ? > pEnv, mhToCall)) != NULL) ) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > 1) The NSK_CPP_STUB2 is trivially >> removed with >> >? ? ? ? ?a refactor >> >? ? ? ? ? >? ? ? >? ? ?(JDK-8210728) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ??to: >> >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >> >? ? ? ? ? > ?pEnv->GetObjectClass(pEnv, >> >? ? ? ? ? >? ? ? >? ? ? > mhToCall)) != NULL) ) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > 2) Then the NSK_JNI_VERIFY, I'd >> like to remove >> >? ? ? ? ?it to and it >> >? ? ? ? ? >? ? ? >? ? ?becomes via >> >? ? ? ? ? >? ? ? >? ? ? > this wrapping of JNIEnv: >> >? ? ? ? ? >? ? ? >? ? ? > if ( ! (mhClass = >> pEnv->GetObjectClass(pEnv, >> >? ? ? ? ?mhToCall)) ) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > 3) Then, via removing the >> assignment, we'd >> >? ? ? ? ?arrive to a: >> >? ? ? ? ? >? ? ? >? ? ? > mhClass = >> pEnv->GetObjectClass(pEnv, mhToCall)); >> >? ? ? ? ? >? ? ? >? ? ? > if (!mhClass) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > Without any loss of checking for >> failures, etc. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > So that is my motivation for most >> of this work >> >? ? ? ? ?with a concrete >> >? ? ? ? ? >? ? ? >? ? ?example >> >? ? ? ? ? >? ? ? >? ? ? > (hopefully it helps drive this >> conversation). >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > I inlined my answers here, let me >> know?what you >> >? ? ? ? ?think. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > On Wed, Sep 19, 2018 at 2:30 PM >> Alex Menkov >> >? ? ? ? ? >? ? ? >? ? ?> >> >? ? ? ? ?> > >> >? ? ? ? ?> >> > >> >> >? ? ? ? ? >? ? ?> >> >? ? ? ? ?> > >> >? ? ? ? ?> >> > >>> >> >? ? ? ? ? >? ? ? >? ? ? > > >> >? ? ? ? ?> > >> >? ? ? ? ? >? ? ?> >> >? ? ? ? ?> >> >> >? ? ? ? ? >? ? ? >? ? ?> >> >? ? ? ? ?> > >> >? ? ? ? ? >? ? ?> >> >? ? ? ? ?> >>>>> wrote: >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?Hi Jc, >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?Updated tests looks good. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?Some notes about implementation. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- FatalOnException implements both >> >? ? ? ? ?verification and error >> >? ? ? ? ? >? ? ? >? ? ?handling >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?It would be better to separate >> them (and >> >? ? ? ? ?this makes >> >? ? ? ? ? >? ? ?easy to >> >? ? ? ? ? >? ? ? >? ? ?implement >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?error handling different from >> >? ? ? ? ?JNIEnv::FatalError). >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?The simplest way is to define >> error handler as >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?class SafeJNIEnv { >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?public: >> >? ? ? ? ? >? ? ? >? ? ? > ?typedef void (*ErrorHandler)(JNIEnv >> >? ? ? ? ?*env, const >> >? ? ? ? ? >? ? ?char* >> >? ? ? ? ? >? ? ? >? ? ?errorMsg); >> >? ? ? ? ? >? ? ? >? ? ? > ?// error handler which terminates jvm >> >? ? ? ? ?by using >> >? ? ? ? ? >? ? ?FatalError() >> >? ? ? ? ? >? ? ? >? ? ? > ?static void FatalError(JNIEnv *env, >> >? ? ? ? ?const char >> >? ? ? ? ? >? ? ?*errrorMsg); >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > ?SafeJNIEnv(JNIEnv* jni_env, >> ErrorHandler >> >? ? ? ? ? >? ? ?errorHandler = >> >? ? ? ? ? >? ? ? >? ? ? > ?FatalError); >> >? ? ? ? ? >? ? ? >? ? ? > ?(SafeJNIEnv methods should create >> >? ? ? ? ?FatalOnException objects >> >? ? ? ? ? >? ? ? >? ? ?passing >> >? ? ? ? ? >? ? ? >? ? ? > ?errorHandler) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > Agreed, I tried to keep the code >> simple. The >> >? ? ? ? ?concepts you >> >? ? ? ? ? >? ? ?talk about >> >? ? ? ? ? >? ? ? >? ? ? > here are generally what I reserve >> for when I >> >? ? ? ? ?need it (ie >> >? ? ? ? ? >? ? ? >? ? ?extensions and >> >? ? ? ? ? >? ? ? >? ? ? > handling new cases). But a lot are >> going to be >> >? ? ? ? ?needed soon >> >? ? ? ? ? >? ? ?so I >> >? ? ? ? ? >? ? ? >? ? ?think it >> >? ? ? ? ? >? ? ? >? ? ? > is a good time to iron the code >> out now on this >> >? ? ? ? ?"simple" >> >? ? ? ? ? >? ? ?webrev. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > So done for this. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- FatalOnException is used in >> SafeJNIEnv >> >? ? ? ? ?methods as >> >? ? ? ? ? >? ? ? >? ? ? > ?FatalOnException marker(this, "msg"); >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?ret = >> >? ? ? ? ? >? ? ? >? ? ? > ?(optional)marker.check_for_null(ret); >> >? ? ? ? ? >? ? ? >? ? ? > ?return ret; >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?But actually I'd call it >> something like >> >? ? ? ? ? >? ? ?JNICallResultVerifier and >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?create >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?the object after JNI call. like >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?ret = >> >? ? ? ? ? >? ? ? >? ? ? > ?JNICallResultVerifier(this, "msg") >> >? ? ? ? ? >? ? ? >? ? ? > ?(optional).notNull(ret); >> >? ? ? ? ? >? ? ? >? ? ? > ?return ret; >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?or even (if you like such >> syntax sugar) you >> >? ? ? ? ?can define >> >? ? ? ? ? >? ? ? >? ? ? > ?template >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?T resultNotNull(T result) { >> >? ? ? ? ? >? ? ? >? ? ? > ?notNull(result); >> >? ? ? ? ? >? ? ? >? ? ? > ?return result; >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?} >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?and do >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? ? ?ret = >> >? ? ? ? ? >? ? ? >? ? ? > ?return JNICallResultVerifier(this, >> >? ? ? ? ? >? ? ?"msg").resultNotNull(ret); >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > So I renamed FatalOnException to >> now being >> >? ? ? ? ?JNIVerifier. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > Though I like it, I don't think we >> can do it, >> >? ? ? ? ?except if we >> >? ? ? ? ? >? ? ?do it >> >? ? ? ? ? >? ? ? >? ? ? > slightly differently: >> >? ? ? ? ? >? ? ? >? ? ? > I'm trying to solve two problems >> with one stone: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- How to check for returns of >> JNI calls in >> >? ? ? ? ?the way that is >> >? ? ? ? ? >? ? ? >? ? ?done here >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- How to remove >> NSK_JNI_VERIFY* (from >> >? ? ? ? ? >? ? ?nsk/share/jni/jni_tools) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > However, the NSK_JNI_VERIFY need >> to start a >> >? ? ? ? ?tracing system >> >? ? ? ? ? >? ? ?before >> >? ? ? ? ? >? ? ? >? ? ?the >> >? ? ? ? ? >? ? ? >? ? ? > call to JNI, so it won't work this >> way. (Side >> >? ? ? ? ?question >> >? ? ? ? ? >? ? ?would be >> >? ? ? ? ? >? ? ? >? ? ?do we >> >? ? ? ? ? >? ? ? >? ? ? > still care about the tracing in >> NSK_JNI_VERIFY, >> >? ? ? ? ?if we >> >? ? ? ? ? >? ? ?don't then >> >? ? ? ? ? >? ? ? >? ? ?your >> >? ? ? ? ? >? ? ? >? ? ? > solution works well in most >> situations). >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > My vision or intuition is that we >> would throw a >> >? ? ? ? ?template >> >? ? ? ? ? >? ? ?at some >> >? ? ? ? ? >? ? ? >? ? ?point >> >? ? ? ? ? >? ? ? >? ? ? > on SafeJNIEnv to handle both cases >> and have >> >? ? ? ? ?JNIVerifier >> >? ? ? ? ? >? ? ?become a >> >? ? ? ? ? >? ? ? >? ? ? > specialization in certain cases >> and something >> >? ? ? ? ?different >> >? ? ? ? ? >? ? ?for the >> >? ? ? ? ? >? ? ? >? ? ? > NSK_JNI_VERIFY case (or have a >> different >> >? ? ? ? ?constructor to enable >> >? ? ? ? ? >? ? ? >? ? ?tracing). >> >? ? ? ? ? >? ? ? >? ? ? > But for now, I offer the >> implementation that does: >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > jclass >> SafeJNIEnv::GetObjectClass(jobject obj) { >> >? ? ? ? ? >? ? ? >? ? ? > JNIVerifier marker(this, >> >? ? ? ? ?"GetObjectClass"); >> >? ? ? ? ? >? ? ? >? ? ? >? ? return >> > ?marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >> >? ? ? ? ? >? ? ? >? ? ? > } >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > and: >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > void >> SafeJNIEnv::SetObjectField(jobject obj, >> >? ? ? ? ?jfieldID >> >? ? ? ? ? >? ? ?field, jobject >> >? ? ? ? ? >? ? ? >? ? ? > value) { >> >? ? ? ? ? >? ? ? >? ? ? > JNIVerifier<> marker(this, >> "SetObjectField"); >> >? ? ? ? ? >? ? ? >? ? ? > _jni_env->SetObjectField(obj, >> field, value); >> >? ? ? ? ? >? ? ? >? ? ? > } >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- you added #include >> in the test >> >? ? ? ? ?(and you have to >> >? ? ? ? ? >? ? ? >? ? ?add it to >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?every test). >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?It would be simpler to add the >> include to >> >? ? ? ? ? >? ? ?SafeJNIEnv.hpp and >> >? ? ? ? ? >? ? ? >? ? ?define >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?typedef >> std::unique_ptr >> >? ? ? ? ?SafeJNIEnvPtr; >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?Then each in the test methods: >> >? ? ? ? ? >? ? ? >? ? ? > ?SafeJNIEnvPtr env(new >> SafeJNIEnv(jni_env)); >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?or you can add >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?static SafeJNIEnv::SafeJNIEnvPtr >> >? ? ? ? ?wrap(JNIEnv* jni_env, >> >? ? ? ? ? >? ? ? >? ? ?ErrorHandler >> >? ? ? ? ? >? ? ? >? ? ? > ?errorHandler = fatalError) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?and get >> >? ? ? ? ? >? ? ? >? ? ? > ?SafeJNIEnvPtr env = >> >? ? ? ? ?SafeJNIEnv::wrap(jni_env); >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > Done, I like that, even less code >> change to >> >? ? ? ? ?tests then. >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- it would be better to wrap >> internal classes >> >? ? ? ? ? >? ? ? > ?(FatalOnException) into >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?unnamed namespace - this helps >> to avoid >> >? ? ? ? ?conflicts with >> >? ? ? ? ? >? ? ?other >> >? ? ? ? ? >? ? ? >? ? ?classes) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?- >> FatalOnException::check_for_null(void* ptr) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?should be >> >? ? ? ? ? >? ? ? >? ? ? > >> ?FatalOnException::check_for_null(const >> >? ? ? ? ?void* ptr) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?And calling the method you >> don't need >> >? ? ? ? ?reinterpret_cast >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > Also done, it got renamed to >> ResultNotNull, is >> >? ? ? ? ?using a >> >? ? ? ? ? >? ? ?template >> >? ? ? ? ? >? ? ? >? ? ?now, but >> >? ? ? ? ? >? ? ? >? ? ? > agreed, that worked. >> >? ? ? ? ? >? ? ? >? ? ? > Thanks again for the review, >> >? ? ? ? ? >? ? ? >? ? ? > Jc >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?--alex >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?On 09/18/2018 11:07, JC Beyler >> wrote: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Hi David, >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Thanks for the quick review and >> >? ? ? ? ?thoughts. I have >> >? ? ? ? ? >? ? ?now a new >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?version here >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > that addresses your comments: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Webrev: >> >? ? ? ? ? >? ? ? > >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >> >> >? ? ? ? >> ? >> >? ? ? ? ? >? ? >> ? >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ?Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > I've also inlined my >> answers/comments. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > I've slowly started >> working on >> >? ? ? ? ?JDK-8191519 >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > >> >? ? ? ? ? >? ? >> ?. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?However before >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > starting to really >> refactor all >> >? ? ? ? ?the tests, I >> >? ? ? ? ? >? ? ? >? ? ?thought I'd >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?get a few >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > opinions.?I am working on >> >? ? ? ? ?internalizing the >> >? ? ? ? ? >? ? ?error >> >? ? ? ? ? >? ? ? >? ? ?handling >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?of JNI >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?calls >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > via a SafeJNIEnv >> class that >> >? ? ? ? ?redefines all >> >? ? ? ? ? >? ? ?the JNI >> >? ? ? ? ? >? ? ? >? ? ?calls to >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?add an >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?error >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > checker. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > The advantage is that >> the test >> >? ? ? ? ?code will >> >? ? ? ? ? >? ? ?look and >> >? ? ? ? ? >? ? ? >? ? ?feel like >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?normal JNI >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > code and calls but >> will have the >> >? ? ? ? ?checks we >> >? ? ? ? ? >? ? ?want to have >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?for our >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?tests. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?Not sure I get that. >> Normal JNI code >> >? ? ? ? ?has to >> >? ? ? ? ? >? ? ?check for >> >? ? ? ? ? >? ? ? >? ? ? > ?errors/exceptions >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?after every call. The >> tests need >> >? ? ? ? ?those checks too. >> >? ? ? ? ? >? ? ? >? ? ?Today they are >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?explicit, with this >> change they become >> >? ? ? ? ? >? ? ?implicit. Not sure >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?what we are >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?gaining here ?? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > In my humble opinion, >> having the error >> >? ? ? ? ?checking out >> >? ? ? ? ? >? ? ?of the way >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?allows >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > the code reader to >> concentrate on the >> >? ? ? ? ?JNI code while >> >? ? ? ? ? >? ? ? >? ? ?maintaining >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?error >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > checking. We use something >> similar >> >? ? ? ? ?internally, so >> >? ? ? ? ? >? ? ?perhaps I'm >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?biased to >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > it :-). >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > If this is not a >> desired/helpful >> >? ? ? ? ?"feature" to simplify >> >? ? ? ? ? >? ? ? >? ? ?tests in >> >? ? ? ? ? >? ? ? >? ? ? > ?general, >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > I will backtrack it and >> just add the >> >? ? ? ? ?explicit tests >> >? ? ? ? ? >? ? ?to the >> >? ? ? ? ? >? ? ? >? ? ?native >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?code >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > of the locks for the fix >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? > >> https://bugs.openjdk.java.net/browse/JDK-8191519?instead. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Let me however try to make >> my case and >> >? ? ? ? ?let me know what >> >? ? ? ? ? >? ? ? >? ? ?you all >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?think! >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > If agreed with this, >> we can >> >? ? ? ? ?augment the >> >? ? ? ? ? >? ? ?SafeJNIEnv >> >? ? ? ? ? >? ? ? >? ? ?class >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?as needed. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > Also, if the tests >> require >> >? ? ? ? ?something else >> >? ? ? ? ? >? ? ?than fatal >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?errors, we >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?can add >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > a different marker >> and make it a >> >? ? ? ? ?parameter >> >? ? ? ? ? >? ? ?to the >> >? ? ? ? ? >? ? ? >? ? ?base class. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > Webrev: >> >? ? ? ? ? >? ? ? >? ? ? > >> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >> >> >? ? ? ? >> ? >> >? ? ? ? ? >? ? >> ? >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > Bug: >> >? ? ? ? ? > https://bugs.openjdk.java.net/browse/JDK-8210842 >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > Let me know what you >> think, >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?Two initial suggestions: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?1. FatalOnException >> should be >> >? ? ? ? ?constructed with a >> >? ? ? ? ? >? ? ? >? ? ?description >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?string so >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?that it can report the >> failing >> >? ? ? ? ?operation when >> >? ? ? ? ? >? ? ?calling >> >? ? ? ? ? >? ? ? >? ? ? > ?FatalError rather >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?than the general >> "Problem with a JNI >> >? ? ? ? ?call". >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Agreed with you, the new >> webrev produces: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > FATAL ERROR in native >> method: GetObjectClass >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?Method) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? > >> ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > and for a return NULL in >> NewGlobalRef, >> >? ? ? ? ?we would get >> >? ? ? ? ? >? ? ? >? ? ?automatically: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > FATAL ERROR in native method: >> >? ? ? ? ?NewGlobalRef:Return >> >? ? ? ? ? >? ? ?is NULL >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?Method) >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? ? ? at >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Again as we port and >> simplify more tests >> >? ? ? ? ?(I'll only >> >? ? ? ? ? >? ? ?do the >> >? ? ? ? ? >? ? ? >? ? ?locks >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?for now >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > and we can figure out the >> next steps as >> >? ? ? ? ?start >> >? ? ? ? ? >? ? ?working on >> >? ? ? ? ? >? ? ? >? ? ?moving >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?tests >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > out of vmTestbase), >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > we can add, if needed, >> other exception >> >? ? ? ? ?handlers >> >? ? ? ? ? >? ? ?that don't >> >? ? ? ? ? >? ? ? >? ? ?throw >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?or do >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > other things depending on >> the JNI method >> >? ? ? ? ?outputs. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?2. Make the local >> SafeJNIEnv a >> >? ? ? ? ?pointer called >> >? ? ? ? ? >? ? ?env so >> >? ? ? ? ? >? ? ? >? ? ?that the >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?change is >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?less disruptive. All the >> env->op() >> >? ? ? ? ?calls will >> >? ? ? ? ? >? ? ?remain >> >? ? ? ? ? >? ? ? >? ? ?and only >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?the local >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?error checking will be >> removed. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Done, I used a unique_ptr >> to make the object >> >? ? ? ? ? >? ? ? >? ? ? > ?created/destroyed/available >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > as a pointer do-able in one >> line: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > std::unique_ptr >> env(new >> >? ? ? ? ? >? ? ?SafeJNIEnv(jni_env)); >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > and then you can see that, >> as you >> >? ? ? ? ?mentioned, the >> >? ? ? ? ? >? ? ?disruption to >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?the code >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > is much less: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >> >> >? ? ? ? >> ? >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Basically the tests now >> become internal >> >? ? ? ? ?to the >> >? ? ? ? ? >? ? ?SafeJNIEnv >> >? ? ? ? ? >? ? ? >? ? ?and the >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?code >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > now only contains the JNI calls >> >? ? ? ? ?happening but we >> >? ? ? ? ? >? ? ?are protected >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?and will >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > fail any test that has an >> exception or a >> >? ? ? ? ?NULL >> >? ? ? ? ? >? ? ?return for the >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?call. Of >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > course, this is not 100% >> proof in terms >> >? ? ? ? ?of not >> >? ? ? ? ? >? ? ?having any >> >? ? ? ? ? >? ? ? >? ? ?error >> >? ? ? ? ? >? ? ? >? ? ? > ?handling >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > in the test but in some >> cases like this, >> >? ? ? ? ?the new >> >? ? ? ? ? >? ? ?code seems to >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?just work >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > better: >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> > >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >> >> >? ? ? ? >> ? >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? > >> >? ? ? ? ? > >> >? ? ? ? ? >> ? >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?The switch from, e.g., >> checking NULL >> >? ? ? ? ?returns to >> >? ? ? ? ? >? ? ? >? ? ?checking for >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?pending >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?exceptions, need to be >> sure that the >> >? ? ? ? ?JNI operations >> >? ? ? ? ? >? ? ? >? ? ?clearly >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?specify >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?that >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?NULL implies there will >> be an exception >> >? ? ? ? ? >? ? ?pending. This >> >? ? ? ? ? >? ? ? >? ? ?change >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?may be an >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?issue for static code >> analysis if >> >? ? ? ? ?not smart >> >? ? ? ? ? >? ? ?enough to >> >? ? ? ? ? >? ? ? >? ? ? > ?understand the >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?RAII wrappers. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Agreed, I fixed it to be >> more strict and >> >? ? ? ? ?say: in >> >? ? ? ? ? >? ? ?normal test >> >? ? ? ? ? >? ? ? >? ? ? > ?handling, >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > the JNI calls should never >> return NULL >> >? ? ? ? ?or throw an >> >? ? ? ? ? >? ? ? >? ? ?exception. This >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > should hold for tests I >> imagine but if >> >? ? ? ? ?not we can add a >> >? ? ? ? ? >? ? ? >? ? ?different >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?call >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > verifier as we go. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?Thanks, >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ?David >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > ? ? > Jc >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Let me know what you all >> think. When >> >? ? ? ? ?talking about it a >> >? ? ? ? ? >? ? ? >? ? ?bit, I had >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > gotten some interest to see >> what it >> >? ? ? ? ?would look >> >? ? ? ? ? >? ? ?like. Here >> >? ? ? ? ? >? ? ? >? ? ?it is >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?:-). Now >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > if it is not wanted like I >> said, I can >> >? ? ? ? ?backtrack >> >? ? ? ? ? >? ? ?and just >> >? ? ? ? ? >? ? ? >? ? ?put the >> >? ? ? ? ? >? ? ? >? ? ? >? ? ?error >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > checks after each JNI call >> for all the >> >? ? ? ? ?tests as we are >> >? ? ? ? ? >? ? ? >? ? ?porting them. >> >? ? ? ? ? >? ? ? >? ? ? >? ? ? > Jc >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? >? ? ? >? ? ? > -- >> >? ? ? ? ? >? ? ? >? ? ? > >> >? ? ? ? ? > >> > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Sep 28 03:57:29 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 27 Sep 2018 20:57:29 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <05f50598-a193-908e-c645-17955b2dc451@oracle.com> References: <7fa2b6fa-ca11-54a6-a214-3906d3347959@oracle.com> <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> <05f50598-a193-908e-c645-17955b2dc451@oracle.com> Message-ID: Hi Serguei, Exactly, I'm taking the lazy approach and just doing the ones I need. Ideally I will find a better means to wrap around the methods without having to redefine all of them but I've looked around and nothing seems really perfect even with heavy utilization of C++ templates. Perhaps I can use some macro definitions to make the code easier to be generated but I did not want to go in either direction now, instead preferring to keep it simple and direct. If you agree, as we add more methods we can always refactor this at some point if someone (or us) finds a better solution to this but that is an internal problem to the exception checking class and won't affect the tests. Does that sound reasonable? Let me know, Jc On Thu, Sep 27, 2018 at 8:00 PM wrote: > Hi Jc, > > Sorry for being late to the party. > The webrev5 looks good to me. > I don't think you have to try to fix the build system. > Avoiding using unique_ptr is good enough. > > Do I understand it right that the ExceptionCheckingJniEnv class > is going to enhanced with more JNI functions? > I'm wonder if it can be anyhow generalized to avoid this. > > Thanks, > Serguei > > > On 9/27/18 2:33 PM, JC Beyler wrote: > > Hi all, > > Sorry to come back to this so late in the game, but somehow when I synced > my hg clone (or the issue was always there and it is a flaky build), it > seems that something in the build might have changed? Basically now it > seems that the build is adding flags that makes my usage of unique_ptr > fail. > > I "think" it is due to the build adding the gnu++98 standard (But this has > been there for a while it seems so most likely a side-effect is it is being > now used): > > CXXSTD_CXXFLAG="-std=gnu++98" > FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG -Werror], > IF_FALSE: [CXXSTD_CXXFLAG=""]) > > (from: > https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4) > but I'm not sure. > > When I remove that flag, my g++ goes to a more recent standard and > unique_ptr works. > > So I now have to ask you all: > 1) Should we try to fix the build system to at least have C++11 for the > C++ tests, then my webrev.04 can stay as is but has to wait for that to > happen > 2) Should we push a new version that does not use unique_ptr? That > solution would look like the following webrev: > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ > > Sorry for the last minute rug pull, > Jc > > On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt < > mikael.vidstedt at oracle.com> wrote: > >> >> Very, very nice! Thanks for adding the comment and renaming the class! >> Ship it! >> >> Cheers, >> Mikael >> >> >> On Sep 27, 2018, at 10:45 AM, JC Beyler wrote: >> >> Hi Mikael and David, >> >> @David: I thought it was implicit but did not want to presume on this one >> because my goal is to start propagating this new class in the test base and >> get the checks to be done implicitly so I was probably being over-cautious >> @Mikael: done and done, what do you think of the comment here : >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html >> >> For all, the new webrev is here: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >> >> Thanks, >> Jc >> >> On Thu, Sep 27, 2018 at 6:03 AM David Holmes >> wrote: >> >>> Sorry Jc, I thought my LGTM was implicit. :) >>> >>> Thanks, >>> David >>> >>> On 26/09/2018 11:52 PM, JC Beyler wrote: >>> > Ping on this, anybody have time to do a review and give a LGTM? Or >>> David >>> > if you have time and will to provide an explicit LGTM :) >>> > >>> > Thanks, >>> > Jc >>> > >>> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler >> > > wrote: >>> > >>> > Hi David, >>> > >>> > Sounds good to me, Alex gave me one LGTM, so it seems I'm waiting >>> > for an explicit LGTM from you or from someone else on this list to >>> > do a review. >>> > >>> > Thanks again for your help, >>> > Jc >>> > >>> > On Sun, Sep 23, 2018 at 9:22 AM David Holmes >>> > > wrote: >>> > >>> > Hi Jc, >>> > >>> > I don't think it is an issue for this to go ahead. If the >>> static >>> > analysis tool has an issue then we can either find out how to >>> > teach it >>> > about this code structure, or else flag the issues as false >>> > positives. >>> > I'd be relying on one of the serviceability team here to handle >>> > that if >>> > the problem arises. >>> > >>> > Thanks, >>> > David >>> > >>> > On 23/09/2018 12:17 PM, JC Beyler wrote: >>> > > Hi David, >>> > > >>> > > No worries with the time to answer; I appreciate the review! >>> > > >>> > > That's a fair point. Is it possible to "describe" to the >>> > static analysis >>> > > tool to "trust" calls made in the SafeJNIEnv class? >>> > > >>> > > Otherwise, do you have any idea on how to go forward? For >>> > what it's >>> > > worth, this current webrev does not try to replace exception >>> > checking >>> > > with the SafeJNIEnv (it actually adds it), so for now the >>> > > question/solution could be delayed. I could continue working >>> > on this in >>> > > the scope of both the nsk/gc/lock/jniref code base and the >>> > NSK_VERIFIER >>> > > macro removal and we can look at how to tackle the cases >>> > where the tests >>> > > are actually calling exception checking (I know my >>> > heapmonitor does for >>> > > example). >>> > > >>> > > Let me know what you think and thanks for the review, >>> > > Jc >>> > > >>> > > >>> > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes >>> > >>> > > >> > >> wrote: >>> > > >>> > > Hi Jc, >>> > > >>> > > Sorry for the delay on getting back to this but I'm >>> > travelling at the >>> > > moment. >>> > > >>> > > This looks quite neat. Thanks also to Alex for all the >>> > suggestions. >>> > > >>> > > My only remaining concern is that static analysis tools >>> > may not like >>> > > this because they may not be able to determine that we >>> > won't make >>> > > subsequent JNI calls when an exception happens in the >>> > first. That's not >>> > > a reason not to do this of course, just flagging that we >>> > may have to do >>> > > something to deal with that problem. >>> > > >>> > > Thanks, >>> > > David >>> > > >>> > > On 20/09/2018 11:56 AM, JC Beyler wrote: >>> > > > Hi Alex, >>> > > > >>> > > > Done here, thanks for the review: >>> > > > >>> > > > Webrev: >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >>> > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> >>> > > > >>> > >>> > > > Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > >>> > > > Thanks again! >>> > > > Jc >>> > > > >>> > > > >>> > > > On Wed, Sep 19, 2018 at 5:13 PM Alex Menkov >>> > > >> > >>> > >> alexey.menkov at oracle.com>> >>> > > > >> > >>> > > >> > >>> wrote: >>> > > > >>> > > > Hi Jc, >>> > > > >>> > > > Looks good to me. >>> > > > A minor note: >>> > > > - I'd move ErrorHandler typedef to SafeJNIEnv >>> > class to avoid >>> > > global >>> > > > namespece pollution (ErrorHandler is too generic >>> > name). >>> > > > >>> > > > --alex >>> > > > >>> > > > On 09/19/2018 15:56, JC Beyler wrote: >>> > > > > Hi Alex, >>> > > > > >>> > > > > I've updated the webrev to: >>> > > > > Webrev: >>> > > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >>> > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> >>> > > > >>> > >>> > > > > >>> > >>> > > > > Bug: >>> > https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > > >>> > > > > That webrev has the code that is shown here in >>> > snippets. >>> > > > > >>> > > > > >>> > > > > Thanks for the reviews, I've relatively >>> > followed your reviews >>> > > > except for >>> > > > > one detail due to me wanting to handle the >>> > NSK_JNI_VERIFY >>> > > macros via >>> > > > > this system as well later down the road. For >>> an >>> > example: >>> > > > > >>> > > > > We currently have in the code: >>> > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >>> > > NSK_CPP_STUB2(GetObjectClass, >>> > > > > pEnv, mhToCall)) != NULL) ) >>> > > > > >>> > > > > 1) The NSK_CPP_STUB2 is trivially removed with >>> > a refactor >>> > > > (JDK-8210728) >>> > > > > >>> > to: >>> > > > > if ( ! NSK_JNI_VERIFY(pEnv, (mhClass = >>> > > pEnv->GetObjectClass(pEnv, >>> > > > > mhToCall)) != NULL) ) >>> > > > > >>> > > > > 2) Then the NSK_JNI_VERIFY, I'd like to remove >>> > it to and it >>> > > > becomes via >>> > > > > this wrapping of JNIEnv: >>> > > > > if ( ! (mhClass = pEnv->GetObjectClass(pEnv, >>> > mhToCall)) ) >>> > > > > >>> > > > > 3) Then, via removing the assignment, we'd >>> > arrive to a: >>> > > > > mhClass = pEnv->GetObjectClass(pEnv, >>> mhToCall)); >>> > > > > if (!mhClass) >>> > > > > >>> > > > > Without any loss of checking for failures, >>> etc. >>> > > > > >>> > > > > So that is my motivation for most of this work >>> > with a concrete >>> > > > example >>> > > > > (hopefully it helps drive this conversation). >>> > > > > >>> > > > > I inlined my answers here, let me know what >>> you >>> > think. >>> > > > > >>> > > > > On Wed, Sep 19, 2018 at 2:30 PM Alex Menkov >>> > > > >> > >>> > >> alexey.menkov at oracle.com>> >>> > > >> > >>> > >> alexey.menkov at oracle.com>>> >>> > > > > >> > >>> > > >> > > >>> > > > >> > >>> > > >> > >>>> wrote: >>> > > > > >>> > > > > Hi Jc, >>> > > > > >>> > > > > Updated tests looks good. >>> > > > > Some notes about implementation. >>> > > > > >>> > > > > - FatalOnException implements both >>> > verification and error >>> > > > handling >>> > > > > It would be better to separate them (and >>> > this makes >>> > > easy to >>> > > > implement >>> > > > > error handling different from >>> > JNIEnv::FatalError). >>> > > > > The simplest way is to define error >>> handler as >>> > > > > class SafeJNIEnv { >>> > > > > public: >>> > > > > typedef void (*ErrorHandler)(JNIEnv >>> > *env, const >>> > > char* >>> > > > errorMsg); >>> > > > > // error handler which terminates >>> jvm >>> > by using >>> > > FatalError() >>> > > > > static void FatalError(JNIEnv *env, >>> > const char >>> > > *errrorMsg); >>> > > > > >>> > > > > SafeJNIEnv(JNIEnv* jni_env, >>> ErrorHandler >>> > > errorHandler = >>> > > > > FatalError); >>> > > > > (SafeJNIEnv methods should create >>> > FatalOnException objects >>> > > > passing >>> > > > > errorHandler) >>> > > > > >>> > > > > >>> > > > > >>> > > > > Agreed, I tried to keep the code simple. The >>> > concepts you >>> > > talk about >>> > > > > here are generally what I reserve for when I >>> > need it (ie >>> > > > extensions and >>> > > > > handling new cases). But a lot are going to be >>> > needed soon >>> > > so I >>> > > > think it >>> > > > > is a good time to iron the code out now on >>> this >>> > "simple" >>> > > webrev. >>> > > > > >>> > > > > So done for this. >>> > > > > >>> > > > > >>> > > > > >>> > > > > - FatalOnException is used in SafeJNIEnv >>> > methods as >>> > > > > FatalOnException marker(this, "msg"); >>> > > > > ret = >>> > > > > (optional)marker.check_for_null(ret); >>> > > > > return ret; >>> > > > > But actually I'd call it something like >>> > > JNICallResultVerifier and >>> > > > > create >>> > > > > the object after JNI call. like >>> > > > > ret = >>> > > > > JNICallResultVerifier(this, "msg") >>> > > > > (optional).notNull(ret); >>> > > > > return ret; >>> > > > > or even (if you like such syntax sugar) >>> you >>> > can define >>> > > > > template >>> > > > > T resultNotNull(T result) { >>> > > > > notNull(result); >>> > > > > return result; >>> > > > > } >>> > > > > and do >>> > > > > ret = >>> > > > > return JNICallResultVerifier(this, >>> > > "msg").resultNotNull(ret); >>> > > > > >>> > > > > >>> > > > > So I renamed FatalOnException to now being >>> > JNIVerifier. >>> > > > > >>> > > > > Though I like it, I don't think we can do it, >>> > except if we >>> > > do it >>> > > > > slightly differently: >>> > > > > I'm trying to solve two problems with one >>> stone: >>> > > > > - How to check for returns of JNI calls in >>> > the way that is >>> > > > done here >>> > > > > - How to remove NSK_JNI_VERIFY* (from >>> > > nsk/share/jni/jni_tools) >>> > > > > >>> > > > > However, the NSK_JNI_VERIFY need to start a >>> > tracing system >>> > > before >>> > > > the >>> > > > > call to JNI, so it won't work this way. (Side >>> > question >>> > > would be >>> > > > do we >>> > > > > still care about the tracing in >>> NSK_JNI_VERIFY, >>> > if we >>> > > don't then >>> > > > your >>> > > > > solution works well in most situations). >>> > > > > >>> > > > > My vision or intuition is that we would throw >>> a >>> > template >>> > > at some >>> > > > point >>> > > > > on SafeJNIEnv to handle both cases and have >>> > JNIVerifier >>> > > become a >>> > > > > specialization in certain cases and something >>> > different >>> > > for the >>> > > > > NSK_JNI_VERIFY case (or have a different >>> > constructor to enable >>> > > > tracing). >>> > > > > But for now, I offer the implementation that >>> does: >>> > > > > >>> > > > > jclass SafeJNIEnv::GetObjectClass(jobject >>> obj) { >>> > > > > JNIVerifier marker(this, >>> > "GetObjectClass"); >>> > > > > return >>> > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >>> > > > > } >>> > > > > >>> > > > > and: >>> > > > > >>> > > > > void SafeJNIEnv::SetObjectField(jobject obj, >>> > jfieldID >>> > > field, jobject >>> > > > > value) { >>> > > > > JNIVerifier<> marker(this, >>> "SetObjectField"); >>> > > > > _jni_env->SetObjectField(obj, field, >>> value); >>> > > > > } >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > - you added #include in the test >>> > (and you have to >>> > > > add it to >>> > > > > every test). >>> > > > > It would be simpler to add the include to >>> > > SafeJNIEnv.hpp and >>> > > > define >>> > > > > typedef std::unique_ptr >>> > SafeJNIEnvPtr; >>> > > > > Then each in the test methods: >>> > > > > SafeJNIEnvPtr env(new >>> SafeJNIEnv(jni_env)); >>> > > > > or you can add >>> > > > > static SafeJNIEnv::SafeJNIEnvPtr >>> > wrap(JNIEnv* jni_env, >>> > > > ErrorHandler >>> > > > > errorHandler = fatalError) >>> > > > > and get >>> > > > > SafeJNIEnvPtr env = >>> > SafeJNIEnv::wrap(jni_env); >>> > > > > >>> > > > > >>> > > > > Done, I like that, even less code change to >>> > tests then. >>> > > > > >>> > > > > >>> > > > > >>> > > > > - it would be better to wrap internal >>> classes >>> > > > (FatalOnException) into >>> > > > > unnamed namespace - this helps to avoid >>> > conflicts with >>> > > other >>> > > > classes) >>> > > > > >>> > > > > - FatalOnException::check_for_null(void* >>> ptr) >>> > > > > should be >>> > > > > FatalOnException::check_for_null(const >>> > void* ptr) >>> > > > > And calling the method you don't need >>> > reinterpret_cast >>> > > > > >>> > > > > >>> > > > > Also done, it got renamed to ResultNotNull, is >>> > using a >>> > > template >>> > > > now, but >>> > > > > agreed, that worked. >>> > > > > Thanks again for the review, >>> > > > > Jc >>> > > > > >>> > > > > >>> > > > > --alex >>> > > > > >>> > > > > >>> > > > > On 09/18/2018 11:07, JC Beyler wrote: >>> > > > > > Hi David, >>> > > > > > >>> > > > > > Thanks for the quick review and >>> > thoughts. I have >>> > > now a new >>> > > > > version here >>> > > > > > that addresses your comments: >>> > > > > > >>> > > > > > Webrev: >>> > > > >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >>> > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> >>> > > > >>> > >>> > > > > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> >>> > > > > > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> >>> > > > > > >>> > Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > > > >>> > > > > > I've also inlined my answers/comments. >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > I've slowly started working on >>> > JDK-8191519 >>> > > > > > > >>> > > . >>> > > > > However before >>> > > > > > > starting to really refactor all >>> > the tests, I >>> > > > thought I'd >>> > > > > get a few >>> > > > > > > opinions. I am working on >>> > internalizing the >>> > > error >>> > > > handling >>> > > > > of JNI >>> > > > > > calls >>> > > > > > > via a SafeJNIEnv class that >>> > redefines all >>> > > the JNI >>> > > > calls to >>> > > > > add an >>> > > > > > error >>> > > > > > > checker. >>> > > > > > > >>> > > > > > > The advantage is that the test >>> > code will >>> > > look and >>> > > > feel like >>> > > > > > normal JNI >>> > > > > > > code and calls but will have the >>> > checks we >>> > > want to have >>> > > > > for our >>> > > > > > tests. >>> > > > > > >>> > > > > > Not sure I get that. Normal JNI >>> code >>> > has to >>> > > check for >>> > > > > errors/exceptions >>> > > > > > after every call. The tests need >>> > those checks too. >>> > > > Today they are >>> > > > > > explicit, with this change they >>> become >>> > > implicit. Not sure >>> > > > > what we are >>> > > > > > gaining here ?? >>> > > > > > >>> > > > > > >>> > > > > > In my humble opinion, having the error >>> > checking out >>> > > of the way >>> > > > > allows >>> > > > > > the code reader to concentrate on the >>> > JNI code while >>> > > > maintaining >>> > > > > error >>> > > > > > checking. We use something similar >>> > internally, so >>> > > perhaps I'm >>> > > > > biased to >>> > > > > > it :-). >>> > > > > > If this is not a desired/helpful >>> > "feature" to simplify >>> > > > tests in >>> > > > > general, >>> > > > > > I will backtrack it and just add the >>> > explicit tests >>> > > to the >>> > > > native >>> > > > > code >>> > > > > > of the locks for the fix >>> > > > > > >>> > > https://bugs.openjdk.java.net/browse/JDK-8191519 instead. >>> > > > > > >>> > > > > > Let me however try to make my case and >>> > let me know what >>> > > > you all >>> > > > > think! >>> > > > > > >>> > > > > > >>> > > > > > > If agreed with this, we can >>> > augment the >>> > > SafeJNIEnv >>> > > > class >>> > > > > as needed. >>> > > > > > > Also, if the tests require >>> > something else >>> > > than fatal >>> > > > > errors, we >>> > > > > > can add >>> > > > > > > a different marker and make it a >>> > parameter >>> > > to the >>> > > > base class. >>> > > > > > > >>> > > > > > > Webrev: >>> > > > > >>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >>> > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.00/> >>> > > > >>> > >>> > > > > >>> > > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.00/> >>> > > > > > >>> > > > >>> > >>> > > > > > > >>> > > > >>> > >>> > > > > > > Bug: >>> > > https://bugs.openjdk.java.net/browse/JDK-8210842 >>> > > > > > > >>> > > > > > > Let me know what you think, >>> > > > > > >>> > > > > > Two initial suggestions: >>> > > > > > >>> > > > > > 1. FatalOnException should be >>> > constructed with a >>> > > > description >>> > > > > string so >>> > > > > > that it can report the failing >>> > operation when >>> > > calling >>> > > > > FatalError rather >>> > > > > > than the general "Problem with a >>> JNI >>> > call". >>> > > > > > >>> > > > > > >>> > > > > > Agreed with you, the new webrev >>> produces: >>> > > > > > >>> > > > > > FATAL ERROR in native method: >>> GetObjectClass >>> > > > > > at >>> > > > > >>> > > > >>> > > >>> > >>> nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >>> > > > > > at >>> > > > > >>> > > >>> > >>> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>> > > > > Method) >>> > > > > > at >>> > > > > >>> > > > >>> > > >>> > >>> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>> > > > > > at >>> > > > > >>> > > > >>> > > >>> > >>> nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >>> > > > > > at >>> > > > > >>> > > java.lang.Thread.run( >>> java.base at 12-internal/Thread.java:834) >>> > > > > > >>> > > > > > >>> > > > > > and for a return NULL in NewGlobalRef, >>> > we would get >>> > > > automatically: >>> > > > > > >>> > > > > > FATAL ERROR in native method: >>> > NewGlobalRef:Return >>> > > is NULL >>> > > > > > at >>> > > > > >>> > > >>> > >>> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>> > > > > Method) >>> > > > > > >>> > > > > > at >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>> > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > Again as we port and simplify more >>> tests >>> > (I'll only >>> > > do the >>> > > > locks >>> > > > > for now >>> > > > > > and we can figure out the next steps as >>> > start >>> > > working on >>> > > > moving >>> > > > > tests >>> > > > > > out of vmTestbase), >>> > > > > > we can add, if needed, other exception >>> > handlers >>> > > that don't >>> > > > throw >>> > > > > or do >>> > > > > > other things depending on the JNI >>> method >>> > outputs. >>> > > > > > >>> > > > > > >>> > > > > > 2. Make the local SafeJNIEnv a >>> > pointer called >>> > > env so >>> > > > that the >>> > > > > change is >>> > > > > > less disruptive. All the env->op() >>> > calls will >>> > > remain >>> > > > and only >>> > > > > the local >>> > > > > > error checking will be removed. >>> > > > > > >>> > > > > > >>> > > > > > Done, I used a unique_ptr to make the >>> object >>> > > > > created/destroyed/available >>> > > > > > as a pointer do-able in one line: >>> > > > > > std::unique_ptr env(new >>> > > SafeJNIEnv(jni_env)); >>> > > > > > >>> > > > > > and then you can see that, as you >>> > mentioned, the >>> > > disruption to >>> > > > > the code >>> > > > > > is much less: >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > >>> > > > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > >>> > > > > >>> > > > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > >>> > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> > >>> > > > > > >>> > > > > > Basically the tests now become internal >>> > to the >>> > > SafeJNIEnv >>> > > > and the >>> > > > > code >>> > > > > > now only contains the JNI calls >>> > happening but we >>> > > are protected >>> > > > > and will >>> > > > > > fail any test that has an exception or >>> a >>> > NULL >>> > > return for the >>> > > > > call. Of >>> > > > > > course, this is not 100% proof in terms >>> > of not >>> > > having any >>> > > > error >>> > > > > handling >>> > > > > > in the test but in some cases like >>> this, >>> > the new >>> > > code seems to >>> > > > > just work >>> > > > > > better: >>> > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > >>> > > > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > >>> > > > > >>> > > > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > >>> > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > < >>> http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > The switch from, e.g., checking >>> NULL >>> > returns to >>> > > > checking for >>> > > > > pending >>> > > > > > exceptions, need to be sure that >>> the >>> > JNI operations >>> > > > clearly >>> > > > > specify >>> > > > > > that >>> > > > > > NULL implies there will be an >>> exception >>> > > pending. This >>> > > > change >>> > > > > may be an >>> > > > > > issue for static code analysis if >>> > not smart >>> > > enough to >>> > > > > understand the >>> > > > > > RAII wrappers. >>> > > > > > >>> > > > > > >>> > > > > > Agreed, I fixed it to be more strict >>> and >>> > say: in >>> > > normal test >>> > > > > handling, >>> > > > > > the JNI calls should never return NULL >>> > or throw an >>> > > > exception. This >>> > > > > > should hold for tests I imagine but if >>> > not we can add a >>> > > > different >>> > > > > call >>> > > > > > verifier as we go. >>> > > > > > >>> > > > > > >>> > > > > > Thanks, >>> > > > > > David >>> > > > > > >>> > > > > > > Jc >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > Let me know what you all think. When >>> > talking about it a >>> > > > bit, I had >>> > > > > > gotten some interest to see what it >>> > would look >>> > > like. Here >>> > > > it is >>> > > > > :-). Now >>> > > > > > if it is not wanted like I said, I can >>> > backtrack >>> > > and just >>> > > > put the >>> > > > > error >>> > > > > > checks after each JNI call for all the >>> > tests as we are >>> > > > porting them. >>> > > > > > Jc >>> > > > > >>> > > > > >>> > > > > >>> > > > > -- >>> > > > > >>> > > >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Sep 28 05:07:17 2018 From: jini.george at oracle.com (Jini George) Date: Fri, 28 Sep 2018 10:37:17 +0530 Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: References: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> Message-ID: <1c69df87-ee80-286b-9611-cbb9b9bebb55@oracle.com> This looks good to me, Fairoz. Thanks, Jini. On 9/26/2018 1:37 PM, Fairoz Matte wrote: > Hi Jini, > > Thanks for pointing out that, yes we cannot make that cleanup for JDK8. > Keeping it very simple and taking only changes required to fix JDK-8164383 > http://cr.openjdk.java.net/~fmatte/8164383/webrev.02/ > > I have verified running "test/serviceability/sa/jmap-hashcode/Test8028623.java" test case (found from one of the duplicate issue of JDK-8164383). > Results are as expected before and after the patch on Solaris 12 and Solaris 10. > > Along with that, I have verified with Internal testing and found no issues > > Thanks, > Fairoz > >> -----Original Message----- >> From: Jini George >> Sent: Tuesday, September 25, 2018 3:48 PM >> To: Fairoz Matte ; serviceability- >> dev at openjdk.java.net >> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 >> when loading dumped core >> >> Hi Fairoz, >> >> I took a better look at the changes and I realized that the cleanup related to >> SOLARIS_11_B159_OR_LATER would be valid for only JDK9 and later. Since >> JDK8 is supported for Solaris 10 too, I believe that the cleanup related >> changes done as a part of JDK-8164383 should not be done for JDK-8. >> >> Thanks! >> Jini. >> >> On 9/24/2018 7:21 PM, Fairoz Matte wrote: >>> Hi Jini, >>> >>>> -----Original Message----- >>>> From: Jini George >>>> Sent: Friday, September 21, 2018 4:07 PM >>>> To: Fairoz Matte ; serviceability- >>>> dev at openjdk.java.net >>>> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on >>>> Solaris 12 when loading dumped core >>>> >>>> Hi Fairoz, >>>> >>>> This looks good to me. One nit which got missed out in the original >>>> change also is that in saproc.cpp, the following comments >>>> >>>> 452 >>>> 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 >>>> >>>> 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later >>>> 477 /*ARGSUSED*/ >>>> >>> >>> I have incorporated above changes >>> >>>> would not be required anymore. And we would not need the wrapper to >>>> the callback routine fill_cframe_list() -- as in, we would need only >>>> one routine with the appropriate arguments passed. But you are free >>>> to ignore this since this was not done as a part of the original change. >>> >>> Removed wrapper_fill_cframe_list function and fill_cframe_list function >> has been used directly. >>> >>> Please find the updated webrev >>> http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ >>> >>> Thanks, >>> Fairoz >>> >>>> >>>> Thanks, >>>> Jini (Not a Reviewer). >>>> >>>> >>>> >>>> On 9/20/2018 7:06 PM, Fairoz Matte wrote: >>>>> Hi, >>>>> >>>>> Kindly review the backport of "JDK-8164383 : jhsdb dumps core on >>>>> Solaris 12 when loading dumped core" to 8u >>>>> >>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ >>>>> >>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 >>>>> >>>>> JDK9 changeset - >>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 >>>>> >>>>> JDK9 review thread - >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-Octob >>>>> er >>>>> /020543.html >>>>> >>>>> Thanks, >>>>> Fairoz >>>>> From fairoz.matte at oracle.com Fri Sep 28 05:10:12 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 27 Sep 2018 22:10:12 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: <1c69df87-ee80-286b-9611-cbb9b9bebb55@oracle.com> References: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> <1c69df87-ee80-286b-9611-cbb9b9bebb55@oracle.com> Message-ID: <93151a49-fa0d-4690-9ea4-b7c4879b17e3@default> Hi Jini, thanks for the review. May I get one more review for this? Thanks, Fairoz > -----Original Message----- > From: Jini George > Sent: Friday, September 28, 2018 10:37 AM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core > > This looks good to me, Fairoz. > > Thanks, > Jini. > > On 9/26/2018 1:37 PM, Fairoz Matte wrote: > > Hi Jini, > > > > Thanks for pointing out that, yes we cannot make that cleanup for JDK8. > > Keeping it very simple and taking only changes required to fix > > JDK-8164383 http://cr.openjdk.java.net/~fmatte/8164383/webrev.02/ > > > > I have verified running "test/serviceability/sa/jmap- > hashcode/Test8028623.java" test case (found from one of the duplicate issue > of JDK-8164383). > > Results are as expected before and after the patch on Solaris 12 and Solaris > 10. > > > > Along with that, I have verified with Internal testing and found no > > issues > > > > Thanks, > > Fairoz > > > >> -----Original Message----- > >> From: Jini George > >> Sent: Tuesday, September 25, 2018 3:48 PM > >> To: Fairoz Matte ; serviceability- > >> dev at openjdk.java.net > >> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on > >> Solaris 12 when loading dumped core > >> > >> Hi Fairoz, > >> > >> I took a better look at the changes and I realized that the cleanup > >> related to SOLARIS_11_B159_OR_LATER would be valid for only JDK9 and > >> later. Since > >> JDK8 is supported for Solaris 10 too, I believe that the cleanup > >> related changes done as a part of JDK-8164383 should not be done for > JDK-8. > >> > >> Thanks! > >> Jini. > >> > >> On 9/24/2018 7:21 PM, Fairoz Matte wrote: > >>> Hi Jini, > >>> > >>>> -----Original Message----- > >>>> From: Jini George > >>>> Sent: Friday, September 21, 2018 4:07 PM > >>>> To: Fairoz Matte ; serviceability- > >>>> dev at openjdk.java.net > >>>> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on > >>>> Solaris 12 when loading dumped core > >>>> > >>>> Hi Fairoz, > >>>> > >>>> This looks good to me. One nit which got missed out in the original > >>>> change also is that in saproc.cpp, the following comments > >>>> > >>>> 452 > >>>> 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 > >>>> > >>>> 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later > >>>> 477 /*ARGSUSED*/ > >>>> > >>> > >>> I have incorporated above changes > >>> > >>>> would not be required anymore. And we would not need the wrapper > to > >>>> the callback routine fill_cframe_list() -- as in, we would need > >>>> only one routine with the appropriate arguments passed. But you are > >>>> free to ignore this since this was not done as a part of the original > change. > >>> > >>> Removed wrapper_fill_cframe_list function and fill_cframe_list > >>> function > >> has been used directly. > >>> > >>> Please find the updated webrev > >>> http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ > >>> > >>> Thanks, > >>> Fairoz > >>> > >>>> > >>>> Thanks, > >>>> Jini (Not a Reviewer). > >>>> > >>>> > >>>> > >>>> On 9/20/2018 7:06 PM, Fairoz Matte wrote: > >>>>> Hi, > >>>>> > >>>>> Kindly review the backport of "JDK-8164383 : jhsdb dumps core on > >>>>> Solaris 12 when loading dumped core" to 8u > >>>>> > >>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ > >>>>> > >>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 > >>>>> > >>>>> JDK9 changeset - > >>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 > >>>>> > >>>>> JDK9 review thread - > >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-Oct > >>>>> ob > >>>>> er > >>>>> /020543.html > >>>>> > >>>>> Thanks, > >>>>> Fairoz > >>>>> From jcbeyler at google.com Fri Sep 28 05:15:23 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 27 Sep 2018 22:15:23 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* Message-ID: Hi all, I continued the NSK_CPP_STUB removal with this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 This does the another set of 50 files of the jvmti subfolder, it is done automatically by the scripts I put in the bug comments. This passes the tests changed on my dev machine. Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Fri Sep 28 07:40:15 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 28 Sep 2018 00:40:15 -0700 (PDT) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <8f78ff9f-a548-5d5f-bdb0-f366877d2226@oracle.com> <8ccc1a0e-d253-4fbd-9d0b-d334cd8b7bb1@default> Message-ID: <8b244f8a-8a18-4637-9b87-66dae4e21f48@default> Thanks David. Thanks, Sharath -----Original Message----- From: David Holmes Sent: Thursday, September 27, 2018 7:43 PM To: Sharath Ballal; Jini Susan George; serviceability-dev Subject: Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file LGTM. Thanks, David On 27/09/2018 1:16 AM, Sharath Ballal wrote: > Can I get one more review from a (R)eviewer please ? > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Wednesday, September 26, 2018 9:57 AM > To: Jini Susan George; serviceability-dev > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Thanks for the review Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Wednesday, September 26, 2018 9:42 AM > To: Sharath Ballal; serviceability-dev > Subject: Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Looks good to me. > > Thanks, > Jini. > > On 9/24/2018 9:19 AM, Sharath Ballal wrote: >> Hi, >> >> Pls review this test fix to add "-Xmx512m" to SA tests which create >> either core file or heap dump, to avoid timeout due to large heap sizes. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ >> >> >> SA tests passed on Mach5 run. >> >> Thanks, >> >> Sharath >> From serguei.spitsyn at oracle.com Fri Sep 28 11:25:39 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Sep 2018 04:25:39 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> <05f50598-a193-908e-c645-17955b2dc451@oracle.com> Message-ID: <89c3cf25-dcfa-de2c-0971-ed09ddd9f518@oracle.com> Hi Jc, I agree it can be refactored later so I'm Okay with the current webrev. Thanks, Serguei On 9/27/18 8:57 PM, JC Beyler wrote: > Hi Serguei, > > Exactly, I'm taking the lazy approach and just doing the ones I need. > Ideally I will find a better means to wrap around the methods without > having to redefine all of them but I've looked around and nothing > seems really perfect even with heavy utilization of C++ templates. > Perhaps I can use some macro definitions to make the code easier to be > generated but I did not want to go in either direction now, instead > preferring to keep it simple and direct. > > If you agree, as we add more methods we can always refactor this at > some point if someone (or us) finds a better solution to this but that > is an internal problem to the exception checking class and won't > affect the tests. > > Does that sound reasonable? > > Let me know, > Jc > > On Thu, Sep 27, 2018 at 8:00 PM > wrote: > > Hi Jc, > > Sorry for being late to the party. > The webrev5 looks good to me. > I don't think you have to try to fix the build system. > Avoiding using unique_ptr is good enough. > > Do I understand it right that the ExceptionCheckingJniEnv class > is going to enhanced with more JNI functions? > I'm wonder if it can be anyhow generalized to avoid this. > > Thanks, > Serguei > ** > > On 9/27/18 2:33 PM, JC Beyler wrote: >> Hi all, >> >> Sorry to come back to this so late in the game, but somehow when >> I synced my hg clone (or the issue was always there and it is a >> flaky build), it seems that something in the build might have >> changed? Basically now it seems that the build is adding flags >> that makes my usage of unique_ptr fail. >> >> I "think" it is due to the build adding the gnu++98 standard (But >> this has been there for a while it seems so most likely a >> side-effect is it is being now used): >> >> ? ? CXXSTD_CXXFLAG="-std=gnu++98" >> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG >> -Werror], >> IF_FALSE: [CXXSTD_CXXFLAG=""]) >> >> (from: >> https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4) >> but I'm not sure. >> >> When I remove that flag, my g++ goes to a more recent standard >> and unique_ptr works. >> >> So I now have to ask you all: >> ? 1) Should we try to fix the build system to at least have C++11 >> for the C++ tests, then my webrev.04 can stay as is but has to >> wait for that to happen >> ? 2) Should we push a new version that does not use unique_ptr? >> That solution would look like the following webrev: >> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ >> >> >> Sorry for the last minute rug pull, >> Jc >> >> On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt >> > >> wrote: >> >> >> Very, very nice! Thanks for adding the comment and renaming >> the class! Ship it! >> >> Cheers, >> Mikael >> >> >>> On Sep 27, 2018, at 10:45 AM, JC Beyler >> > wrote: >>> >>> Hi Mikael and David, >>> >>> @David: I thought it was implicit but did not want to >>> presume on this one because my goal is to start propagating >>> this new class in the test base and get the checks to be >>> done implicitly so I was probably being over-cautious >>> @Mikael: done and done, what do you think of the comment >>> here : >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html >>> >>> >>> For all, the new webrev is here: >>> Webrev: >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >>> >>> Thanks, >>> Jc >>> >>> On Thu, Sep 27, 2018 at 6:03 AM David Holmes >>> > >>> wrote: >>> >>> Sorry Jc, I thought my LGTM was implicit. :) >>> >>> Thanks, >>> David >>> >>> On 26/09/2018 11:52 PM, JC Beyler wrote: >>> > Ping on this, anybody have time to do a review and >>> give a LGTM? Or David >>> > if you have time and will to provide an explicit LGTM :) >>> > >>> > Thanks, >>> > Jc >>> > >>> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler >>> >>> > >> >> wrote: >>> > >>> >? ? ?Hi David, >>> > >>> >? ? ?Sounds good to me, Alex gave me one LGTM, so it >>> seems I'm waiting >>> >? ? ?for an explicit LGTM from you or from someone else >>> on this list to >>> >? ? ?do a review. >>> > >>> >? ? ?Thanks again for your help, >>> >? ? ?Jc >>> > >>> >? ? ?On Sun, Sep 23, 2018 at 9:22 AM David Holmes >>> >? ? ?>> >>> >> >> wrote: >>> > >>> >? ? ? ? ?Hi Jc, >>> > >>> >? ? ? ? ?I don't think it is an issue for this to go >>> ahead. If the static >>> >? ? ? ? ?analysis tool has an issue then we can either >>> find out how to >>> >? ? ? ? ?teach it >>> >? ? ? ? ?about this code structure, or else flag the >>> issues as false >>> >? ? ? ? ?positives. >>> >? ? ? ? ?I'd be relying on one of the serviceability >>> team here to handle >>> >? ? ? ? ?that if >>> >? ? ? ? ?the problem arises. >>> > >>> >? ? ? ? ?Thanks, >>> >? ? ? ? ?David >>> > >>> >? ? ? ? ?On 23/09/2018 12:17 PM, JC Beyler wrote: >>> >? ? ? ? ? > Hi David, >>> >? ? ? ? ? > >>> >? ? ? ? ? > No worries with the time to answer; I >>> appreciate the review! >>> >? ? ? ? ? > >>> >? ? ? ? ? > That's a fair point. Is it possible to >>> "describe" to the >>> >? ? ? ? ?static analysis >>> >? ? ? ? ? > tool to "trust" calls made in the >>> SafeJNIEnv class? >>> >? ? ? ? ? > >>> >? ? ? ? ? > Otherwise, do you have any idea on how to >>> go forward? For >>> >? ? ? ? ?what it's >>> >? ? ? ? ? > worth, this current webrev does not try to >>> replace exception >>> >? ? ? ? ?checking >>> >? ? ? ? ? > with the SafeJNIEnv (it actually adds it), >>> so for now the >>> >? ? ? ? ? > question/solution could be delayed. I could >>> continue working >>> >? ? ? ? ?on this in >>> >? ? ? ? ? > the scope of both the nsk/gc/lock/jniref >>> code base and the >>> >? ? ? ? ?NSK_VERIFIER >>> >? ? ? ? ? > macro removal and we can look at how to >>> tackle the cases >>> >? ? ? ? ?where the tests >>> >? ? ? ? ? > are actually calling exception checking (I >>> know my >>> >? ? ? ? ?heapmonitor does for >>> >? ? ? ? ? > example). >>> >? ? ? ? ? > >>> >? ? ? ? ? > Let me know what you think and thanks for >>> the review, >>> >? ? ? ? ? > Jc >>> >? ? ? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? > On Sun, Sep 23, 2018 at 6:48 AM David Holmes >>> >? ? ? ? ?>> >>> >> > >>> >? ? ? ? ? > >> >>> >? ? ? ? ?>> >>> wrote: >>> >? ? ? ? ? > >>> >? ? ? ? ? >? ? ?Hi Jc, >>> >? ? ? ? ? > >>> >? ? ? ? ? >? ? ?Sorry for the delay on getting back to >>> this but I'm >>> >? ? ? ? ?travelling at the >>> >? ? ? ? ? >? ? ?moment. >>> >? ? ? ? ? > >>> >? ? ? ? ? >? ? ?This looks quite neat. Thanks also to >>> Alex for all the >>> >? ? ? ? ?suggestions. >>> >? ? ? ? ? > >>> >? ? ? ? ? >? ? ?My only remaining concern is that >>> static analysis tools >>> >? ? ? ? ?may not like >>> >? ? ? ? ? >? ? ?this because they may not be able to >>> determine that we >>> >? ? ? ? ?won't make >>> >? ? ? ? ? >? ? ?subsequent JNI calls when an exception >>> happens in the >>> >? ? ? ? ?first. That's not >>> >? ? ? ? ? >? ? ?a reason not to do this of course, just >>> flagging that we >>> >? ? ? ? ?may have to do >>> >? ? ? ? ? >? ? ?something to deal with that problem. >>> >? ? ? ? ? > >>> >? ? ? ? ? >? ? ?Thanks, >>> >? ? ? ? ? >? ? ?David >>> >? ? ? ? ? > >>> >? ? ? ? ? >? ? ?On 20/09/2018 11:56 AM, JC Beyler wrote: >>> >? ? ? ? ? >? ? ? > Hi Alex, >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > Done here, thanks for the review: >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > Webrev: >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >>> >>> >? ? ? ? >>> ? >>> >? ? ? ? ? >? ? >>> ? >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? > Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8210842 >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > Thanks again! >>> >? ? ? ? ? >? ? ? > Jc >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > On Wed, Sep 19, 2018 at 5:13 PM Alex >>> Menkov >>> >? ? ? ? ? >? ? ?>> >>> >? ? ? ? ?>> > >>> >? ? ? ? ?>> >>> >> >> >>> >? ? ? ? ? >? ? ? > >> >>> >? ? ? ? ?>> > >>> >? ? ? ? ? >? ? ?>> >>> >? ? ? ? ?>> >>>> wrote: >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ?Hi Jc, >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ?Looks good to me. >>> >? ? ? ? ? >? ? ? >? ? ?A minor note: >>> >? ? ? ? ? >? ? ? >? ? ?- I'd move ErrorHandler typedef >>> to SafeJNIEnv >>> >? ? ? ? ?class to avoid >>> >? ? ? ? ? >? ? ?global >>> >? ? ? ? ? >? ? ? >? ? ?namespece pollution >>> (ErrorHandler is too generic >>> >? ? ? ? ?name). >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ?--alex >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ?On 09/19/2018 15:56, JC Beyler >>> wrote: >>> >? ? ? ? ? >? ? ? >? ? ? > Hi Alex, >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > I've updated the webrev to: >>> >? ? ? ? ? >? ? ? >? ? ? > Webrev: >>> >? ? ? ? ? > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >>> >>> >? ? ? ? >>> ? >>> >? ? ? ? ? >? ? >>> ? >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > Bug: >>> > https://bugs.openjdk.java.net/browse/JDK-8210842 >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > That webrev has the code that >>> is shown here in >>> >? ? ? ? ?snippets. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > Thanks for the reviews, I've >>> relatively >>> >? ? ? ? ?followed your reviews >>> >? ? ? ? ? >? ? ? >? ? ?except for >>> >? ? ? ? ? >? ? ? >? ? ? > one detail due to me wanting >>> to handle the >>> >? ? ? ? ?NSK_JNI_VERIFY >>> >? ? ? ? ? >? ? ?macros via >>> >? ? ? ? ? >? ? ? >? ? ? > this system as well later >>> down the road. For an >>> >? ? ? ? ?example: >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > We currently have in the code: >>> >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, >>> (mhClass = >>> >? ? ? ? ? > ?NSK_CPP_STUB2(GetObjectClass, >>> >? ? ? ? ? >? ? ? >? ? ? > pEnv, mhToCall)) != NULL) ) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > 1) The NSK_CPP_STUB2 is >>> trivially removed with >>> >? ? ? ? ?a refactor >>> >? ? ? ? ? >? ? ? > ?(JDK-8210728) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? >>> ??to: >>> >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, >>> (mhClass = >>> >? ? ? ? ? > ?pEnv->GetObjectClass(pEnv, >>> >? ? ? ? ? >? ? ? >? ? ? > mhToCall)) != NULL) ) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > 2) Then the NSK_JNI_VERIFY, >>> I'd like to remove >>> >? ? ? ? ?it to and it >>> >? ? ? ? ? >? ? ? >? ? ?becomes via >>> >? ? ? ? ? >? ? ? >? ? ? > this wrapping of JNIEnv: >>> >? ? ? ? ? >? ? ? >? ? ? > if ( ! (mhClass = >>> pEnv->GetObjectClass(pEnv, >>> >? ? ? ? ?mhToCall)) ) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > 3) Then, via removing the >>> assignment, we'd >>> >? ? ? ? ?arrive to a: >>> >? ? ? ? ? >? ? ? >? ? ? > mhClass = >>> pEnv->GetObjectClass(pEnv, mhToCall)); >>> >? ? ? ? ? >? ? ? >? ? ? > if (!mhClass) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > Without any loss of checking >>> for failures, etc. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > So that is my motivation for >>> most of this work >>> >? ? ? ? ?with a concrete >>> >? ? ? ? ? >? ? ? >? ? ?example >>> >? ? ? ? ? >? ? ? >? ? ? > (hopefully it helps drive >>> this conversation). >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > I inlined my answers here, >>> let me know?what you >>> >? ? ? ? ?think. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > On Wed, Sep 19, 2018 at 2:30 >>> PM Alex Menkov >>> >? ? ? ? ? >? ? ? >? ? ?>> >>> >? ? ? ? ?>> > >>> >? ? ? ? ?>> >>> >> >> >>> >? ? ? ? ? >? ? ?>> >>> >? ? ? ? ?>> > >>> >? ? ? ? ?>> >>> >> >>> >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >> >>> >? ? ? ? ?>> > >>> >? ? ? ? ? >? ? ?>> >>> >? ? ? ? ?>> >> >>> >? ? ? ? ? >? ? ? > ?>> >>> >? ? ? ? ?>> > >>> >? ? ? ? ? >? ? ?>> >>> >? ? ? ? ?>> >>>>> wrote: >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?Hi Jc, >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?Updated tests looks good. >>> >? ? ? ? ? >? ? ? >? ? ? > ?Some notes about implementation. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?- FatalOnException >>> implements both >>> >? ? ? ? ?verification and error >>> >? ? ? ? ? >? ? ? >? ? ?handling >>> >? ? ? ? ? >? ? ? >? ? ? > ?It would be better to >>> separate them (and >>> >? ? ? ? ?this makes >>> >? ? ? ? ? >? ? ?easy to >>> >? ? ? ? ? >? ? ? >? ? ?implement >>> >? ? ? ? ? >? ? ? >? ? ? > ?error handling different from >>> >? ? ? ? ?JNIEnv::FatalError). >>> >? ? ? ? ? >? ? ? >? ? ? > ?The simplest way is to >>> define error handler as >>> >? ? ? ? ? >? ? ? >? ? ? > ?class SafeJNIEnv { >>> >? ? ? ? ? >? ? ? >? ? ? > ?public: >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?typedef void >>> (*ErrorHandler)(JNIEnv >>> >? ? ? ? ?*env, const >>> >? ? ? ? ? >? ? ?char* >>> >? ? ? ? ? >? ? ? > ?errorMsg); >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?// error handler which >>> terminates jvm >>> >? ? ? ? ?by using >>> >? ? ? ? ? >? ? ?FatalError() >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?static void >>> FatalError(JNIEnv *env, >>> >? ? ? ? ?const char >>> >? ? ? ? ? >? ? ?*errrorMsg); >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?SafeJNIEnv(JNIEnv* >>> jni_env, ErrorHandler >>> >? ? ? ? ? >? ? ?errorHandler = >>> >? ? ? ? ? >? ? ? >? ? ? > ?FatalError); >>> >? ? ? ? ? >? ? ? >? ? ? > ?(SafeJNIEnv methods should >>> create >>> >? ? ? ? ?FatalOnException objects >>> >? ? ? ? ? >? ? ? >? ? ?passing >>> >? ? ? ? ? >? ? ? >? ? ? > ?errorHandler) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > Agreed, I tried to keep the >>> code simple. The >>> >? ? ? ? ?concepts you >>> >? ? ? ? ? >? ? ?talk about >>> >? ? ? ? ? >? ? ? >? ? ? > here are generally what I >>> reserve for when I >>> >? ? ? ? ?need it (ie >>> >? ? ? ? ? >? ? ? > ?extensions and >>> >? ? ? ? ? >? ? ? >? ? ? > handling new cases). But a >>> lot are going to be >>> >? ? ? ? ?needed soon >>> >? ? ? ? ? >? ? ?so I >>> >? ? ? ? ? >? ? ? >? ? ?think it >>> >? ? ? ? ? >? ? ? >? ? ? > is a good time to iron the >>> code out now on this >>> >? ? ? ? ?"simple" >>> >? ? ? ? ? >? ? ?webrev. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > So done for this. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?- FatalOnException is used >>> in SafeJNIEnv >>> >? ? ? ? ?methods as >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?FatalOnException >>> marker(this, "msg"); >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?ret = >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? >>> ?(optional)marker.check_for_null(ret); >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?return ret; >>> >? ? ? ? ? >? ? ? >? ? ? > ?But actually I'd call it >>> something like >>> >? ? ? ? ? > ?JNICallResultVerifier and >>> >? ? ? ? ? >? ? ? >? ? ? > ?create >>> >? ? ? ? ? >? ? ? >? ? ? > ?the object after JNI call. like >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?ret = >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? >>> ?JNICallResultVerifier(this, "msg") >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?(optional).notNull(ret); >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?return ret; >>> >? ? ? ? ? >? ? ? >? ? ? > ?or even (if you like such >>> syntax sugar) you >>> >? ? ? ? ?can define >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?template >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?T resultNotNull(T result) { >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ? ?notNull(result); >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ? ?return result; >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?} >>> >? ? ? ? ? >? ? ? >? ? ? > ?and do >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?ret = >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?return >>> JNICallResultVerifier(this, >>> >? ? ? ? ? > ?"msg").resultNotNull(ret); >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > So I renamed FatalOnException >>> to now being >>> >? ? ? ? ?JNIVerifier. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > Though I like it, I don't >>> think we can do it, >>> >? ? ? ? ?except if we >>> >? ? ? ? ? >? ? ?do it >>> >? ? ? ? ? >? ? ? >? ? ? > slightly differently: >>> >? ? ? ? ? >? ? ? >? ? ? > I'm trying to solve two >>> problems with one stone: >>> >? ? ? ? ? >? ? ? >? ? ? > ?- How to check for returns >>> of JNI calls in >>> >? ? ? ? ?the way that is >>> >? ? ? ? ? >? ? ? >? ? ?done here >>> >? ? ? ? ? >? ? ? >? ? ? > ?- How to remove >>> NSK_JNI_VERIFY* (from >>> >? ? ? ? ? > ?nsk/share/jni/jni_tools) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > However, the NSK_JNI_VERIFY >>> need to start a >>> >? ? ? ? ?tracing system >>> >? ? ? ? ? >? ? ?before >>> >? ? ? ? ? >? ? ? >? ? ?the >>> >? ? ? ? ? >? ? ? >? ? ? > call to JNI, so it won't work >>> this way. (Side >>> >? ? ? ? ?question >>> >? ? ? ? ? >? ? ?would be >>> >? ? ? ? ? >? ? ? >? ? ?do we >>> >? ? ? ? ? >? ? ? >? ? ? > still care about the tracing >>> in NSK_JNI_VERIFY, >>> >? ? ? ? ?if we >>> >? ? ? ? ? >? ? ?don't then >>> >? ? ? ? ? >? ? ? >? ? ?your >>> >? ? ? ? ? >? ? ? >? ? ? > solution works well in most >>> situations). >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > My vision or intuition is >>> that we would throw a >>> >? ? ? ? ?template >>> >? ? ? ? ? >? ? ?at some >>> >? ? ? ? ? >? ? ? >? ? ?point >>> >? ? ? ? ? >? ? ? >? ? ? > on SafeJNIEnv to handle both >>> cases and have >>> >? ? ? ? ?JNIVerifier >>> >? ? ? ? ? >? ? ?become a >>> >? ? ? ? ? >? ? ? >? ? ? > specialization in certain >>> cases and something >>> >? ? ? ? ?different >>> >? ? ? ? ? >? ? ?for the >>> >? ? ? ? ? >? ? ? >? ? ? > NSK_JNI_VERIFY case (or have >>> a different >>> >? ? ? ? ?constructor to enable >>> >? ? ? ? ? >? ? ? >? ? ?tracing). >>> >? ? ? ? ? >? ? ? >? ? ? > But for now, I offer the >>> implementation that does: >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > jclass >>> SafeJNIEnv::GetObjectClass(jobject obj) { >>> >? ? ? ? ? >? ? ? >? ? ? > JNIVerifier marker(this, >>> >? ? ? ? ?"GetObjectClass"); >>> >? ? ? ? ? >? ? ? >? ? ? > return >>> > ?marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >>> >? ? ? ? ? >? ? ? >? ? ? > } >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > and: >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > void >>> SafeJNIEnv::SetObjectField(jobject obj, >>> >? ? ? ? ?jfieldID >>> >? ? ? ? ? >? ? ?field, jobject >>> >? ? ? ? ? >? ? ? >? ? ? > value) { >>> >? ? ? ? ? >? ? ? >? ? ? > JNIVerifier<> marker(this, >>> "SetObjectField"); >>> >? ? ? ? ? >? ? ? >? ? ? > _jni_env->SetObjectField(obj, >>> field, value); >>> >? ? ? ? ? >? ? ? >? ? ? > } >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?- you added #include >>> in the test >>> >? ? ? ? ?(and you have to >>> >? ? ? ? ? >? ? ? >? ? ?add it to >>> >? ? ? ? ? >? ? ? >? ? ? > ?every test). >>> >? ? ? ? ? >? ? ? >? ? ? > ?It would be simpler to add >>> the include to >>> >? ? ? ? ? >? ? ?SafeJNIEnv.hpp and >>> >? ? ? ? ? >? ? ? >? ? ?define >>> >? ? ? ? ? >? ? ? >? ? ? > ?typedef >>> std::unique_ptr >>> >? ? ? ? ?SafeJNIEnvPtr; >>> >? ? ? ? ? >? ? ? >? ? ? > ?Then each in the test methods: >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?SafeJNIEnvPtr env(new >>> SafeJNIEnv(jni_env)); >>> >? ? ? ? ? >? ? ? >? ? ? > ?or you can add >>> >? ? ? ? ? >? ? ? >? ? ? > ?static SafeJNIEnv::SafeJNIEnvPtr >>> >? ? ? ? ?wrap(JNIEnv* jni_env, >>> >? ? ? ? ? >? ? ? > ?ErrorHandler >>> >? ? ? ? ? >? ? ? >? ? ? > ?errorHandler = fatalError) >>> >? ? ? ? ? >? ? ? >? ? ? > ?and get >>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?SafeJNIEnvPtr env = >>> >? ? ? ? ?SafeJNIEnv::wrap(jni_env); >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > Done, I like that, even less >>> code change to >>> >? ? ? ? ?tests then. >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?- it would be better to wrap >>> internal classes >>> >? ? ? ? ? >? ? ? > ?(FatalOnException) into >>> >? ? ? ? ? >? ? ? >? ? ? > ?unnamed namespace - this >>> helps to avoid >>> >? ? ? ? ?conflicts with >>> >? ? ? ? ? >? ? ?other >>> >? ? ? ? ? >? ? ? >? ? ?classes) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?- >>> FatalOnException::check_for_null(void* ptr) >>> >? ? ? ? ? >? ? ? >? ? ? > ?should be >>> >? ? ? ? ? >? ? ? >? ? ? > >>> ?FatalOnException::check_for_null(const >>> >? ? ? ? ?void* ptr) >>> >? ? ? ? ? >? ? ? >? ? ? > ?And calling the method you >>> don't need >>> >? ? ? ? ?reinterpret_cast >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > Also done, it got renamed to >>> ResultNotNull, is >>> >? ? ? ? ?using a >>> >? ? ? ? ? >? ? ?template >>> >? ? ? ? ? >? ? ? >? ? ?now, but >>> >? ? ? ? ? >? ? ? >? ? ? > agreed, that worked. >>> >? ? ? ? ? >? ? ? >? ? ? > Thanks again for the review, >>> >? ? ? ? ? >? ? ? >? ? ? > Jc >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?--alex >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ?On 09/18/2018 11:07, JC >>> Beyler wrote: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Hi David, >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Thanks for the quick >>> review and >>> >? ? ? ? ?thoughts. I have >>> >? ? ? ? ? >? ? ?now a new >>> >? ? ? ? ? >? ? ? >? ? ? > ?version here >>> >? ? ? ? ? >? ? ? >? ? ? > ? > that addresses your comments: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Webrev: >>> >? ? ? ? ? >? ? ? > >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >>> >>> >? ? ? ? >>> ? >>> >? ? ? ? ? >? ? >>> ? >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? >>> ?Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > I've also inlined my >>> answers/comments. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > I've slowly >>> started working on >>> >? ? ? ? ?JDK-8191519 >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>> >? ? ? ? ? >? ? >>> ?. >>> >? ? ? ? ? >? ? ? >? ? ? > ?However before >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > starting to really >>> refactor all >>> >? ? ? ? ?the tests, I >>> >? ? ? ? ? >? ? ? >? ? ?thought I'd >>> >? ? ? ? ? >? ? ? >? ? ? > ?get a few >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > opinions.?I am >>> working on >>> >? ? ? ? ?internalizing the >>> >? ? ? ? ? >? ? ?error >>> >? ? ? ? ? >? ? ? >? ? ?handling >>> >? ? ? ? ? >? ? ? >? ? ? > ?of JNI >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?calls >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > via a SafeJNIEnv >>> class that >>> >? ? ? ? ?redefines all >>> >? ? ? ? ? >? ? ?the JNI >>> >? ? ? ? ? >? ? ? >? ? ?calls to >>> >? ? ? ? ? >? ? ? >? ? ? > ?add an >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?error >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > checker. >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > The advantage is >>> that the test >>> >? ? ? ? ?code will >>> >? ? ? ? ? >? ? ?look and >>> >? ? ? ? ? >? ? ? >? ? ?feel like >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?normal JNI >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > code and calls but >>> will have the >>> >? ? ? ? ?checks we >>> >? ? ? ? ? >? ? ?want to have >>> >? ? ? ? ? >? ? ? >? ? ? > ?for our >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?tests. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?Not sure I get that. >>> Normal JNI code >>> >? ? ? ? ?has to >>> >? ? ? ? ? >? ? ?check for >>> >? ? ? ? ? >? ? ? >? ? ? > ?errors/exceptions >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?after every call. The >>> tests need >>> >? ? ? ? ?those checks too. >>> >? ? ? ? ? >? ? ? >? ? ?Today they are >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?explicit, with this >>> change they become >>> >? ? ? ? ? >? ? ?implicit. Not sure >>> >? ? ? ? ? >? ? ? >? ? ? > ?what we are >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?gaining here ?? >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > In my humble opinion, >>> having the error >>> >? ? ? ? ?checking out >>> >? ? ? ? ? >? ? ?of the way >>> >? ? ? ? ? >? ? ? >? ? ? > ?allows >>> >? ? ? ? ? >? ? ? >? ? ? > ? > the code reader to >>> concentrate on the >>> >? ? ? ? ?JNI code while >>> >? ? ? ? ? >? ? ? > ?maintaining >>> >? ? ? ? ? >? ? ? >? ? ? > ?error >>> >? ? ? ? ? >? ? ? >? ? ? > ? > checking. We use >>> something similar >>> >? ? ? ? ?internally, so >>> >? ? ? ? ? >? ? ?perhaps I'm >>> >? ? ? ? ? >? ? ? >? ? ? > ?biased to >>> >? ? ? ? ? >? ? ? >? ? ? > ? > it :-). >>> >? ? ? ? ? >? ? ? >? ? ? > ? > If this is not a >>> desired/helpful >>> >? ? ? ? ?"feature" to simplify >>> >? ? ? ? ? >? ? ? >? ? ?tests in >>> >? ? ? ? ? >? ? ? >? ? ? > ?general, >>> >? ? ? ? ? >? ? ? >? ? ? > ? > I will backtrack it and >>> just add the >>> >? ? ? ? ?explicit tests >>> >? ? ? ? ? >? ? ?to the >>> >? ? ? ? ? >? ? ? >? ? ?native >>> >? ? ? ? ? >? ? ? >? ? ? > ?code >>> >? ? ? ? ? >? ? ? >? ? ? > ? > of the locks for the fix >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? > >>> https://bugs.openjdk.java.net/browse/JDK-8191519?instead. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Let me however try to >>> make my case and >>> >? ? ? ? ?let me know what >>> >? ? ? ? ? >? ? ? >? ? ?you all >>> >? ? ? ? ? >? ? ? >? ? ? > ?think! >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > If agreed with >>> this, we can >>> >? ? ? ? ?augment the >>> >? ? ? ? ? >? ? ?SafeJNIEnv >>> >? ? ? ? ? >? ? ? >? ? ?class >>> >? ? ? ? ? >? ? ? >? ? ? > ?as needed. >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Also, if the tests >>> require >>> >? ? ? ? ?something else >>> >? ? ? ? ? >? ? ?than fatal >>> >? ? ? ? ? >? ? ? >? ? ? > ?errors, we >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?can add >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > a different marker >>> and make it a >>> >? ? ? ? ?parameter >>> >? ? ? ? ? >? ? ?to the >>> >? ? ? ? ? >? ? ? >? ? ?base class. >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Webrev: >>> >? ? ? ? ? >? ? ? >? ? ? > >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >>> >>> >? ? ? ? >>> ? >>> >? ? ? ? ? >? ? >>> ? >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Bug: >>> >? ? ? ? ? > >>> https://bugs.openjdk.java.net/browse/JDK-8210842 >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Let me know what >>> you think, >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?Two initial suggestions: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?1. FatalOnException >>> should be >>> >? ? ? ? ?constructed with a >>> >? ? ? ? ? >? ? ? > ?description >>> >? ? ? ? ? >? ? ? >? ? ? > ?string so >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?that it can report >>> the failing >>> >? ? ? ? ?operation when >>> >? ? ? ? ? >? ? ?calling >>> >? ? ? ? ? >? ? ? >? ? ? > ?FatalError rather >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?than the general >>> "Problem with a JNI >>> >? ? ? ? ?call". >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Agreed with you, the new >>> webrev produces: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > FATAL ERROR in native >>> method: GetObjectClass >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>> >? ? ? ? ? >? ? ? >? ? ? > ?Method) >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? > >>> ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834 >>> ) >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > and for a return NULL in >>> NewGlobalRef, >>> >? ? ? ? ?we would get >>> >? ? ? ? ? >? ? ? > ?automatically: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > FATAL ERROR in native method: >>> >? ? ? ? ?NewGlobalRef:Return >>> >? ? ? ? ? >? ? ?is NULL >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>> >? ? ? ? ? >? ? ? >? ? ? > ?Method) >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Again as we port and >>> simplify more tests >>> >? ? ? ? ?(I'll only >>> >? ? ? ? ? >? ? ?do the >>> >? ? ? ? ? >? ? ? >? ? ?locks >>> >? ? ? ? ? >? ? ? >? ? ? > ?for now >>> >? ? ? ? ? >? ? ? >? ? ? > ? > and we can figure out the >>> next steps as >>> >? ? ? ? ?start >>> >? ? ? ? ? >? ? ?working on >>> >? ? ? ? ? >? ? ? >? ? ?moving >>> >? ? ? ? ? >? ? ? >? ? ? > ?tests >>> >? ? ? ? ? >? ? ? >? ? ? > ? > out of vmTestbase), >>> >? ? ? ? ? >? ? ? >? ? ? > ? > we can add, if needed, >>> other exception >>> >? ? ? ? ?handlers >>> >? ? ? ? ? >? ? ?that don't >>> >? ? ? ? ? >? ? ? >? ? ?throw >>> >? ? ? ? ? >? ? ? >? ? ? > ?or do >>> >? ? ? ? ? >? ? ? >? ? ? > ? > other things depending on >>> the JNI method >>> >? ? ? ? ?outputs. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?2. Make the local >>> SafeJNIEnv a >>> >? ? ? ? ?pointer called >>> >? ? ? ? ? >? ? ?env so >>> >? ? ? ? ? >? ? ? >? ? ?that the >>> >? ? ? ? ? >? ? ? >? ? ? > ?change is >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?less disruptive. All >>> the env->op() >>> >? ? ? ? ?calls will >>> >? ? ? ? ? >? ? ?remain >>> >? ? ? ? ? >? ? ? >? ? ?and only >>> >? ? ? ? ? >? ? ? >? ? ? > ?the local >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?error checking will >>> be removed. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Done, I used a unique_ptr >>> to make the object >>> >? ? ? ? ? >? ? ? >? ? ? > ?created/destroyed/available >>> >? ? ? ? ? >? ? ? >? ? ? > ? > as a pointer do-able in >>> one line: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> std::unique_ptr env(new >>> >? ? ? ? ? > ?SafeJNIEnv(jni_env)); >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > and then you can see >>> that, as you >>> >? ? ? ? ?mentioned, the >>> >? ? ? ? ? >? ? ?disruption to >>> >? ? ? ? ? >? ? ? >? ? ? > ?the code >>> >? ? ? ? ? >? ? ? >? ? ? > ? > is much less: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>> >>> >? ? ? ? >>> ? >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Basically the tests now >>> become internal >>> >? ? ? ? ?to the >>> >? ? ? ? ? >? ? ?SafeJNIEnv >>> >? ? ? ? ? >? ? ? >? ? ?and the >>> >? ? ? ? ? >? ? ? >? ? ? > ?code >>> >? ? ? ? ? >? ? ? >? ? ? > ? > now only contains the JNI >>> calls >>> >? ? ? ? ?happening but we >>> >? ? ? ? ? >? ? ?are protected >>> >? ? ? ? ? >? ? ? >? ? ? > ?and will >>> >? ? ? ? ? >? ? ? >? ? ? > ? > fail any test that has an >>> exception or a >>> >? ? ? ? ?NULL >>> >? ? ? ? ? >? ? ?return for the >>> >? ? ? ? ? >? ? ? >? ? ? > ?call. Of >>> >? ? ? ? ? >? ? ? >? ? ? > ? > course, this is not 100% >>> proof in terms >>> >? ? ? ? ?of not >>> >? ? ? ? ? >? ? ?having any >>> >? ? ? ? ? >? ? ? >? ? ?error >>> >? ? ? ? ? >? ? ? >? ? ? > ?handling >>> >? ? ? ? ? >? ? ? >? ? ? > ? > in the test but in some >>> cases like this, >>> >? ? ? ? ?the new >>> >? ? ? ? ? >? ? ?code seems to >>> >? ? ? ? ? >? ? ? >? ? ? > ?just work >>> >? ? ? ? ? >? ? ? >? ? ? > ? > better: >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>> >>> >? ? ? ? >>> ? >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >? ? ? ? ? >>> ? >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?The switch from, >>> e.g., checking NULL >>> >? ? ? ? ?returns to >>> >? ? ? ? ? >? ? ? >? ? ?checking for >>> >? ? ? ? ? >? ? ? >? ? ? > ?pending >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?exceptions, need to >>> be sure that the >>> >? ? ? ? ?JNI operations >>> >? ? ? ? ? >? ? ? >? ? ?clearly >>> >? ? ? ? ? >? ? ? >? ? ? > ?specify >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?that >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?NULL implies there >>> will be an exception >>> >? ? ? ? ? >? ? ?pending. This >>> >? ? ? ? ? >? ? ? >? ? ?change >>> >? ? ? ? ? >? ? ? >? ? ? > ?may be an >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?issue for static code >>> analysis if >>> >? ? ? ? ?not smart >>> >? ? ? ? ? >? ? ?enough to >>> >? ? ? ? ? >? ? ? >? ? ? > ?understand the >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?RAII wrappers. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Agreed, I fixed it to be >>> more strict and >>> >? ? ? ? ?say: in >>> >? ? ? ? ? >? ? ?normal test >>> >? ? ? ? ? >? ? ? >? ? ? > ?handling, >>> >? ? ? ? ? >? ? ? >? ? ? > ? > the JNI calls should >>> never return NULL >>> >? ? ? ? ?or throw an >>> >? ? ? ? ? >? ? ? > ?exception. This >>> >? ? ? ? ? >? ? ? >? ? ? > ? > should hold for tests I >>> imagine but if >>> >? ? ? ? ?not we can add a >>> >? ? ? ? ? >? ? ? >? ? ?different >>> >? ? ? ? ? >? ? ? >? ? ? > ?call >>> >? ? ? ? ? >? ? ? >? ? ? > ? > verifier as we go. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?Thanks, >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?David >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Jc >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Let me know what you all >>> think. When >>> >? ? ? ? ?talking about it a >>> >? ? ? ? ? >? ? ? >? ? ?bit, I had >>> >? ? ? ? ? >? ? ? >? ? ? > ? > gotten some interest to >>> see what it >>> >? ? ? ? ?would look >>> >? ? ? ? ? >? ? ?like. Here >>> >? ? ? ? ? >? ? ? >? ? ?it is >>> >? ? ? ? ? >? ? ? >? ? ? > ?:-). Now >>> >? ? ? ? ? >? ? ? >? ? ? > ? > if it is not wanted like >>> I said, I can >>> >? ? ? ? ?backtrack >>> >? ? ? ? ? >? ? ?and just >>> >? ? ? ? ? >? ? ? >? ? ?put the >>> >? ? ? ? ? >? ? ? >? ? ? > ?error >>> >? ? ? ? ? >? ? ? >? ? ? > ? > checks after each JNI >>> call for all the >>> >? ? ? ? ?tests as we are >>> >? ? ? ? ? >? ? ? >? ? ?porting them. >>> >? ? ? ? ? >? ? ? >? ? ? > ? > Jc >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? >? ? ? >? ? ? > -- >>> >? ? ? ? ? >? ? ? >? ? ? > >>> >? ? ? ? ? > >>> >> >> >> -- >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Sep 28 11:47:42 2018 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 28 Sep 2018 07:47:42 -0400 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> Message-ID: <5BAE14DE.4040305@oracle.com> Revised webrev: Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ The final fix includes - updated the timeout for the test (should handle sparc debug slowness) - wait for explicit prompts from cont command (avoids confusion from "int[2]") - fixed a typo in an exclude pattern ("jdk.*") - on wait for message timeout, don't wait for prompt when dumping current Should have another reviewer in addition to Chris. On 9/27/18, 3:12 PM, Chris Plummer wrote: > The extra check after timing out doesn't seem like it should help. > You've already called findMessage() 2100 times at 200ms intervals. Why > would one more call after that help? I think it might be the > receiveReply() call that is fixing it. It does a waitForPrompt(), so > this probably gives us another 420000 ms for the prompt to come in. > This call to receiveReply() is actually a bug itself since we are > doing it just to print the current buffer, not the buffer after > waiting for a prompt to come in. > > In any case, looks like this prompt is taking more than 420200 > milliseconds to come in, but does eventually come in, and extra > waiting in receiveReply() is what is causing you to eventually see the > prompt. I think bumping up the timeout to 600 and the waittime to 10 > is the proper fix here. > > And to address the receiveReply() issue, I'd suggest calling it using > receiveReply(startPos, false, 0), where 0 is the prompt count, and > have receiveReply() not wait for a prompt when the count is 0. > > Chris > > On 9/27/18 11:44 AM, Gary Adams wrote: >> Speaking of not being bullet proof, during testing of the fix to >> wait for a specific prompt an intermittent failure was observed. >> ... >> >> Sending command: trace methods 0x2a9 >> reply[0]: MyThread-0[1] >> Sending command: cont >> WARNING: message not recieved: MyThread-0[1] >> Remaining debugger output follows: >> reply[0]:> >> reply[1]: Method exited: return value =, >> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >> line=93 bci=14 >> reply[2]: 93 } >> reply[3]: >> reply[4]: MyThread-0[1] >> # ERROR: Caught unexpected exception while executing the test: >> nsk.share.Failure: Expected message not received during 420200 >> milliseconds: >> ... >> >> The wait for message times out looking for "MyThread-0[1]". >> A WARNING is printed and the "remaining debugger output" >> shows that "MyThread-0[1]" is in the buffer. >> >> I'm still investigating why the message match is not found. >> >> Adding a final check before failing the wait for message >> seems to workaround the problem. >> >> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >> @@ -515,10 +515,11 @@ >> long delta = 200; // time in milliseconds to wait at every >> iteration. >> long total = 0; // total time has waited. >> long max = >> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; // >> maximum time to wait. >> + int found = 0; >> >> Object dummy = new Object(); >> while ((total += delta) <= max) { >> - int found = 0; >> + found = 0; >> >> // search for message >> { >> @@ -553,6 +554,12 @@ >> log.display("WARNING: message not recieved: " + message); >> log.display("Remaining debugger output follows:"); >> receiveReply(startPos); >> + >> + // One last chance >> + found = findMessage(startPos, message); >> + if (found > 0) { >> + return found; >> + } >> throw new Failure("Expected message not received during " + >> total + " milliseconds:" >> + "\n\t" + message); >> } >> >> >> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>> Looks good. Still not bullet proof, but I'm not sure it's possible >>> to write tests like this in a way that will work no matter what >>> output is produced by the method enter/exit events. >>> >>> Chris >>> >>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>> The test failure has been identified due to the "int[2]" >>>> being misrecognized as a compound prompt. This caused a cont >>>> command to be sent prematurely. >>>> >>>> The proposed fix waits for the correct prompt before >>>> advancing to the next command. >>>> >>>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>> >>>> Testing is in progress. >>> >>> >>> >> > > From gary.adams at oracle.com Fri Sep 28 12:17:05 2018 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 28 Sep 2018 08:17:05 -0400 Subject: JDK-8203350: Crash in vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java In-Reply-To: References: <5BACCAB0.1050806@oracle.com> Message-ID: <5BAE1BC1.5030405@oracle.com> At this point my first recommendation is to simply remove the test from the ProblemList, since it has not been reproduced after 1000s of testruns with debug and release builds. What is not clear to me at the moment is - was it intentional that hs201t001 intentionally placed the classloader operation outside of doInit() and hs201t002 placed the classloader operation in the doInit() method. It appears that the primary purpose of these two tests is the difference in behavior for IsMethodObsolete. My best guess is that at some point the classloader operation was failing after a RedefineClasses, and a workaround was introduced into hs201t001. Later on the same issue was observed with hs201t002, which did not have the same workaround in place. My primary goal is to make the test reliable for functionality it is intended to exercise. My secondary goal is to have some consistency between these similar tests. From the discussions in the related issues, the crashes were not able to be reproduced so the issues were resolved as CNR. It was presumed that some other fix accounted for the problem no longer being visible. On 9/27/18, 2:34 PM, Chris Plummer wrote: > Hi Gary, > > Aren't you just hiding a potential jvmti bug with this change? If you > think this is a test bug and this is a proper fix, I'd like to see an > explanation of how the test is causing the crash. The explanation > would need to involve native code, since pure java should never crash. > > thanks, > > Chris > > On 9/27/18 5:18 AM, Gary Adams wrote: >> I've been unsuccessful trying to reproduce the failure in hs201t002. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8203350 >> >> Colleen made a comment on the bug that the reference >> from hs201t002a to class hs201t002 might be an issue >> for the redefined class. >> >> I found in test hs201t001 that an intentional reference >> before entering hs201t001a.doInit() is made to avoid >> that classloader operation. >> >> It's not clear to me why that was done, but the same workaround >> could be used in hs201t002a, if it would make the test more robust. >> >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >> >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >> @@ -26,6 +26,7 @@ >> public class hs201t002a extends Exception { >> >> public hs201t002a () { >> + System.out.println("Current step: " + >> hs201t002.currentStep); // Avoid calling classloader to find >> hs201t002 in doInit() >> doInit(); >> } >> > > From goetz.lindenmaier at sap.com Fri Sep 28 15:10:45 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 28 Sep 2018 15:10:45 +0000 Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> Message-ID: <07713e7d6f9b481d8b9a3570d97a2586@sap.com> Hi Sharath, what do you think about bringing this fix to jdk11u? We run the tests there regularly and see this problem, too. Best regards, Goetz. > -----Original Message----- > From: serviceability-dev On > Behalf Of Sharath Ballal > Sent: Montag, 24. September 2018 05:49 > To: serviceability-dev > Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times > out parsing a 4GB hprof file > > Hi, > > > > Pls review this test fix to add "-Xmx512m" to SA tests which create either > core file or heap dump, to avoid timeout due to large heap sizes. > > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > > > SA tests passed on Mach5 run. > > > > Thanks, > > Sharath > > > > From alexey.menkov at oracle.com Fri Sep 28 17:20:49 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 28 Sep 2018 10:20:49 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: References: Message-ID: <2cd251ec-61df-b701-a9f2-a75efb2c732a@oracle.com> Hi Jc, Overall looks good. Could you please update ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp manually - converted calls contain a lot of unnecessary spaces. --alex On 09/27/2018 22:15, JC Beyler wrote: > Hi all, > > I continued the NSK_CPP_STUB removal with this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > This does the another set of 50 files of the jvmti subfolder, it is done > automatically by the scripts I put in the bug comments. > > This passes the tests changed on my dev machine. > > Let me know what you think, > Jc From alexey.menkov at oracle.com Fri Sep 28 17:30:03 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 28 Sep 2018 10:30:03 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <89c3cf25-dcfa-de2c-0971-ed09ddd9f518@oracle.com> References: <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> <05f50598-a193-908e-c645-17955b2dc451@oracle.com> <89c3cf25-dcfa-de2c-0971-ed09ddd9f518@oracle.com> Message-ID: <4b523285-e604-0cab-8c58-79aa5fa8731d@oracle.com> +1 for webrev.05 --alex On 09/28/2018 04:25, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > I agree it can be refactored later so I'm Okay with the current webrev. > > Thanks, > Serguei > > On 9/27/18 8:57 PM, JC Beyler wrote: >> Hi Serguei, >> >> Exactly, I'm taking the lazy approach and just doing the ones I need. >> Ideally I will find a better means to wrap around the methods without >> having to redefine all of them but I've looked around and nothing >> seems really perfect even with heavy utilization of C++ templates. >> Perhaps I can use some macro definitions to make the code easier to be >> generated but I did not want to go in either direction now, instead >> preferring to keep it simple and direct. >> >> If you agree, as we add more methods we can always refactor this at >> some point if someone (or us) finds a better solution to this but that >> is an internal problem to the exception checking class and won't >> affect the tests. >> >> Does that sound reasonable? >> >> Let me know, >> Jc >> >> On Thu, Sep 27, 2018 at 8:00 PM > > wrote: >> >> Hi Jc, >> >> Sorry for being late to the party. >> The webrev5 looks good to me. >> I don't think you have to try to fix the build system. >> Avoiding using unique_ptr is good enough. >> >> Do I understand it right that the ExceptionCheckingJniEnv class >> is going to enhanced with more JNI functions? >> I'm wonder if it can be anyhow generalized to avoid this. >> >> Thanks, >> Serguei >> ** >> >> On 9/27/18 2:33 PM, JC Beyler wrote: >>> Hi all, >>> >>> Sorry to come back to this so late in the game, but somehow when >>> I synced my hg clone (or the issue was always there and it is a >>> flaky build), it seems that something in the build might have >>> changed? Basically now it seems that the build is adding flags >>> that makes my usage of unique_ptr fail. >>> >>> I "think" it is due to the build adding the gnu++98 standard (But >>> this has been there for a while it seems so most likely a >>> side-effect is it is being now used): >>> >>> ? ? CXXSTD_CXXFLAG="-std=gnu++98" >>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG >>> -Werror], >>> IF_FALSE: [CXXSTD_CXXFLAG=""]) >>> >>> (from: >>> https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4) >>> but I'm not sure. >>> >>> When I remove that flag, my g++ goes to a more recent standard >>> and unique_ptr works. >>> >>> So I now have to ask you all: >>> ? 1) Should we try to fix the build system to at least have C++11 >>> for the C++ tests, then my webrev.04 can stay as is but has to >>> wait for that to happen >>> ? 2) Should we push a new version that does not use unique_ptr? >>> That solution would look like the following webrev: >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ >>> >>> >>> Sorry for the last minute rug pull, >>> Jc >>> >>> On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt >>> > >>> wrote: >>> >>> >>> Very, very nice! Thanks for adding the comment and renaming >>> the class! Ship it! >>> >>> Cheers, >>> Mikael >>> >>> >>>> On Sep 27, 2018, at 10:45 AM, JC Beyler >>> > wrote: >>>> >>>> Hi Mikael and David, >>>> >>>> @David: I thought it was implicit but did not want to >>>> presume on this one because my goal is to start propagating >>>> this new class in the test base and get the checks to be >>>> done implicitly so I was probably being over-cautious >>>> @Mikael: done and done, what do you think of the comment >>>> here : >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html >>>> >>>> >>>> For all, the new webrev is here: >>>> Webrev: >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 >>>> >>>> Thanks, >>>> Jc >>>> >>>> On Thu, Sep 27, 2018 at 6:03 AM David Holmes >>>> > >>>> wrote: >>>> >>>> Sorry Jc, I thought my LGTM was implicit. :) >>>> >>>> Thanks, >>>> David >>>> >>>> On 26/09/2018 11:52 PM, JC Beyler wrote: >>>> > Ping on this, anybody have time to do a review and >>>> give a LGTM? Or David >>>> > if you have time and will to provide an explicit LGTM :) >>>> > >>>> > Thanks, >>>> > Jc >>>> > >>>> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler >>>> >>>> > >>> >> wrote: >>>> > >>>> >? ? ?Hi David, >>>> > >>>> >? ? ?Sounds good to me, Alex gave me one LGTM, so it >>>> seems I'm waiting >>>> >? ? ?for an explicit LGTM from you or from someone else >>>> on this list to >>>> >? ? ?do a review. >>>> > >>>> >? ? ?Thanks again for your help, >>>> >? ? ?Jc >>>> > >>>> >? ? ?On Sun, Sep 23, 2018 at 9:22 AM David Holmes >>>> >? ? ?>>> >>>> >>> >> wrote: >>>> > >>>> >? ? ? ? ?Hi Jc, >>>> > >>>> >? ? ? ? ?I don't think it is an issue for this to go >>>> ahead. If the static >>>> >? ? ? ? ?analysis tool has an issue then we can either >>>> find out how to >>>> >? ? ? ? ?teach it >>>> >? ? ? ? ?about this code structure, or else flag the >>>> issues as false >>>> >? ? ? ? ?positives. >>>> >? ? ? ? ?I'd be relying on one of the serviceability >>>> team here to handle >>>> >? ? ? ? ?that if >>>> >? ? ? ? ?the problem arises. >>>> > >>>> >? ? ? ? ?Thanks, >>>> >? ? ? ? ?David >>>> > >>>> >? ? ? ? ?On 23/09/2018 12:17 PM, JC Beyler wrote: >>>> >? ? ? ? ? > Hi David, >>>> >? ? ? ? ? > >>>> >? ? ? ? ? > No worries with the time to answer; I >>>> appreciate the review! >>>> >? ? ? ? ? > >>>> >? ? ? ? ? > That's a fair point. Is it possible to >>>> "describe" to the >>>> >? ? ? ? ?static analysis >>>> >? ? ? ? ? > tool to "trust" calls made in the >>>> SafeJNIEnv class? >>>> >? ? ? ? ? > >>>> >? ? ? ? ? > Otherwise, do you have any idea on how to >>>> go forward? For >>>> >? ? ? ? ?what it's >>>> >? ? ? ? ? > worth, this current webrev does not try to >>>> replace exception >>>> >? ? ? ? ?checking >>>> >? ? ? ? ? > with the SafeJNIEnv (it actually adds it), >>>> so for now the >>>> >? ? ? ? ? > question/solution could be delayed. I could >>>> continue working >>>> >? ? ? ? ?on this in >>>> >? ? ? ? ? > the scope of both the nsk/gc/lock/jniref >>>> code base and the >>>> >? ? ? ? ?NSK_VERIFIER >>>> >? ? ? ? ? > macro removal and we can look at how to >>>> tackle the cases >>>> >? ? ? ? ?where the tests >>>> >? ? ? ? ? > are actually calling exception checking (I >>>> know my >>>> >? ? ? ? ?heapmonitor does for >>>> >? ? ? ? ? > example). >>>> >? ? ? ? ? > >>>> >? ? ? ? ? > Let me know what you think and thanks for >>>> the review, >>>> >? ? ? ? ? > Jc >>>> >? ? ? ? ? > >>>> >? ? ? ? ? > >>>> >? ? ? ? ? > On Sun, Sep 23, 2018 at 6:48 AM David Holmes >>>> >? ? ? ? ?>>> >>>> >>> > >>>> >? ? ? ? ? > >>> >>>> >? ? ? ? ?>>> >>> wrote: >>>> >? ? ? ? ? > >>>> >? ? ? ? ? >? ? ?Hi Jc, >>>> >? ? ? ? ? > >>>> >? ? ? ? ? >? ? ?Sorry for the delay on getting back to >>>> this but I'm >>>> >? ? ? ? ?travelling at the >>>> >? ? ? ? ? >? ? ?moment. >>>> >? ? ? ? ? > >>>> >? ? ? ? ? >? ? ?This looks quite neat. Thanks also to >>>> Alex for all the >>>> >? ? ? ? ?suggestions. >>>> >? ? ? ? ? > >>>> >? ? ? ? ? >? ? ?My only remaining concern is that >>>> static analysis tools >>>> >? ? ? ? ?may not like >>>> >? ? ? ? ? >? ? ?this because they may not be able to >>>> determine that we >>>> >? ? ? ? ?won't make >>>> >? ? ? ? ? >? ? ?subsequent JNI calls when an exception >>>> happens in the >>>> >? ? ? ? ?first. That's not >>>> >? ? ? ? ? >? ? ?a reason not to do this of course, just >>>> flagging that we >>>> >? ? ? ? ?may have to do >>>> >? ? ? ? ? >? ? ?something to deal with that problem. >>>> >? ? ? ? ? > >>>> >? ? ? ? ? >? ? ?Thanks, >>>> >? ? ? ? ? >? ? ?David >>>> >? ? ? ? ? > >>>> >? ? ? ? ? >? ? ?On 20/09/2018 11:56 AM, JC Beyler wrote: >>>> >? ? ? ? ? >? ? ? > Hi Alex, >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > Done here, thanks for the review: >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > Webrev: >>>> > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ >>>> >>>> > >>>> ? >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? > Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8210842 >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > Thanks again! >>>> >? ? ? ? ? >? ? ? > Jc >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > On Wed, Sep 19, 2018 at 5:13 PM Alex >>>> Menkov >>>> >? ? ? ? ? >? ? ?>>> >>>> >? ? ? ? ?>>> > >>>> >? ? ? ? ?>>> >>>> >>> >> >>>> >? ? ? ? ? >? ? ? > >>> >>>> >? ? ? ? ?>>> > >>>> >? ? ? ? ? >? ? ?>>> >>>> >? ? ? ? ?>>> >>>> wrote: >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ?Hi Jc, >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ?Looks good to me. >>>> >? ? ? ? ? >? ? ? >? ? ?A minor note: >>>> >? ? ? ? ? >? ? ? >? ? ?- I'd move ErrorHandler typedef >>>> to SafeJNIEnv >>>> >? ? ? ? ?class to avoid >>>> >? ? ? ? ? >? ? ?global >>>> >? ? ? ? ? >? ? ? >? ? ?namespece pollution >>>> (ErrorHandler is too generic >>>> >? ? ? ? ?name). >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ?--alex >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ?On 09/19/2018 15:56, JC Beyler >>>> wrote: >>>> >? ? ? ? ? >? ? ? >? ? ? > Hi Alex, >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > I've updated the webrev to: >>>> >? ? ? ? ? >? ? ? >? ? ? > Webrev: >>>> >? ? ? ? ? > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ >>>> >>>> > >>>> ? >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > Bug: >>>> > https://bugs.openjdk.java.net/browse/JDK-8210842 >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > That webrev has the code that >>>> is shown here in >>>> >? ? ? ? ?snippets. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > Thanks for the reviews, I've >>>> relatively >>>> >? ? ? ? ?followed your reviews >>>> >? ? ? ? ? >? ? ? >? ? ?except for >>>> >? ? ? ? ? >? ? ? >? ? ? > one detail due to me wanting >>>> to handle the >>>> >? ? ? ? ?NSK_JNI_VERIFY >>>> >? ? ? ? ? >? ? ?macros via >>>> >? ? ? ? ? >? ? ? >? ? ? > this system as well later >>>> down the road. For an >>>> >? ? ? ? ?example: >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > We currently have in the code: >>>> >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, >>>> (mhClass = >>>> >? ? ? ? ? > ?NSK_CPP_STUB2(GetObjectClass, >>>> >? ? ? ? ? >? ? ? >? ? ? > pEnv, mhToCall)) != NULL) ) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > 1) The NSK_CPP_STUB2 is >>>> trivially removed with >>>> >? ? ? ? ?a refactor >>>> >? ? ? ? ? >? ? ? > ?(JDK-8210728) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> > >>>> ??to: >>>> >? ? ? ? ? >? ? ? >? ? ? > if ( ! NSK_JNI_VERIFY(pEnv, >>>> (mhClass = >>>> >? ? ? ? ? > ?pEnv->GetObjectClass(pEnv, >>>> >? ? ? ? ? >? ? ? >? ? ? > mhToCall)) != NULL) ) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > 2) Then the NSK_JNI_VERIFY, >>>> I'd like to remove >>>> >? ? ? ? ?it to and it >>>> >? ? ? ? ? >? ? ? >? ? ?becomes via >>>> >? ? ? ? ? >? ? ? >? ? ? > this wrapping of JNIEnv: >>>> >? ? ? ? ? >? ? ? >? ? ? > if ( ! (mhClass = >>>> pEnv->GetObjectClass(pEnv, >>>> >? ? ? ? ?mhToCall)) ) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > 3) Then, via removing the >>>> assignment, we'd >>>> >? ? ? ? ?arrive to a: >>>> >? ? ? ? ? >? ? ? >? ? ? > mhClass = >>>> pEnv->GetObjectClass(pEnv, mhToCall)); >>>> >? ? ? ? ? >? ? ? >? ? ? > if (!mhClass) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > Without any loss of checking >>>> for failures, etc. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > So that is my motivation for >>>> most of this work >>>> >? ? ? ? ?with a concrete >>>> >? ? ? ? ? >? ? ? >? ? ?example >>>> >? ? ? ? ? >? ? ? >? ? ? > (hopefully it helps drive >>>> this conversation). >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > I inlined my answers here, >>>> let me know?what you >>>> >? ? ? ? ?think. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > On Wed, Sep 19, 2018 at 2:30 >>>> PM Alex Menkov >>>> >? ? ? ? ? >? ? ? >? ? ?>>> >>>> >? ? ? ? ?>>> > >>>> >? ? ? ? ?>>> >>>> >>> >> >>>> >? ? ? ? ? >? ? ?>>> >>>> >? ? ? ? ?>>> > >>>> >? ? ? ? ?>>> >>>> >>> >>> >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >>> >>>> >? ? ? ? ?>>> > >>>> >? ? ? ? ? >? ? ?>>> >>>> >? ? ? ? ?>>> >> >>>> >? ? ? ? ? >? ? ? > ?>>> >>>> >? ? ? ? ?>>> > >>>> >? ? ? ? ? >? ? ?>>> >>>> >? ? ? ? ?>>> >>>>> wrote: >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?Hi Jc, >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?Updated tests looks good. >>>> >? ? ? ? ? >? ? ? >? ? ? > ?Some notes about implementation. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- FatalOnException >>>> implements both >>>> >? ? ? ? ?verification and error >>>> >? ? ? ? ? >? ? ? >? ? ?handling >>>> >? ? ? ? ? >? ? ? >? ? ? > ?It would be better to >>>> separate them (and >>>> >? ? ? ? ?this makes >>>> >? ? ? ? ? >? ? ?easy to >>>> >? ? ? ? ? >? ? ? >? ? ?implement >>>> >? ? ? ? ? >? ? ? >? ? ? > ?error handling different from >>>> >? ? ? ? ?JNIEnv::FatalError). >>>> >? ? ? ? ? >? ? ? >? ? ? > ?The simplest way is to >>>> define error handler as >>>> >? ? ? ? ? >? ? ? >? ? ? > ?class SafeJNIEnv { >>>> >? ? ? ? ? >? ? ? >? ? ? > ?public: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?typedef void >>>> (*ErrorHandler)(JNIEnv >>>> >? ? ? ? ?*env, const >>>> >? ? ? ? ? >? ? ?char* >>>> >? ? ? ? ? >? ? ? > ?errorMsg); >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?// error handler which >>>> terminates jvm >>>> >? ? ? ? ?by using >>>> >? ? ? ? ? >? ? ?FatalError() >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?static void >>>> FatalError(JNIEnv *env, >>>> >? ? ? ? ?const char >>>> >? ? ? ? ? >? ? ?*errrorMsg); >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?SafeJNIEnv(JNIEnv* >>>> jni_env, ErrorHandler >>>> >? ? ? ? ? >? ? ?errorHandler = >>>> >? ? ? ? ? >? ? ? >? ? ? > ?FatalError); >>>> >? ? ? ? ? >? ? ? >? ? ? > ?(SafeJNIEnv methods should >>>> create >>>> >? ? ? ? ?FatalOnException objects >>>> >? ? ? ? ? >? ? ? >? ? ?passing >>>> >? ? ? ? ? >? ? ? >? ? ? > ?errorHandler) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > Agreed, I tried to keep the >>>> code simple. The >>>> >? ? ? ? ?concepts you >>>> >? ? ? ? ? >? ? ?talk about >>>> >? ? ? ? ? >? ? ? >? ? ? > here are generally what I >>>> reserve for when I >>>> >? ? ? ? ?need it (ie >>>> >? ? ? ? ? >? ? ? > ?extensions and >>>> >? ? ? ? ? >? ? ? >? ? ? > handling new cases). But a >>>> lot are going to be >>>> >? ? ? ? ?needed soon >>>> >? ? ? ? ? >? ? ?so I >>>> >? ? ? ? ? >? ? ? >? ? ?think it >>>> >? ? ? ? ? >? ? ? >? ? ? > is a good time to iron the >>>> code out now on this >>>> >? ? ? ? ?"simple" >>>> >? ? ? ? ? >? ? ?webrev. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > So done for this. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- FatalOnException is used >>>> in SafeJNIEnv >>>> >? ? ? ? ?methods as >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?FatalOnException >>>> marker(this, "msg"); >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?ret = >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> ?(optional)marker.check_for_null(ret); >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?return ret; >>>> >? ? ? ? ? >? ? ? >? ? ? > ?But actually I'd call it >>>> something like >>>> >? ? ? ? ? > ?JNICallResultVerifier and >>>> >? ? ? ? ? >? ? ? >? ? ? > ?create >>>> >? ? ? ? ? >? ? ? >? ? ? > ?the object after JNI call. like >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?ret = >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> ?JNICallResultVerifier(this, "msg") >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ?(optional).notNull(ret); >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?return ret; >>>> >? ? ? ? ? >? ? ? >? ? ? > ?or even (if you like such >>>> syntax sugar) you >>>> >? ? ? ? ?can define >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?template >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?T resultNotNull(T result) { >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ? ?notNull(result); >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ? ? ?return result; >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?} >>>> >? ? ? ? ? >? ? ? >? ? ? > ?and do >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?ret = >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?return >>>> JNICallResultVerifier(this, >>>> >? ? ? ? ? > ?"msg").resultNotNull(ret); >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > So I renamed FatalOnException >>>> to now being >>>> >? ? ? ? ?JNIVerifier. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > Though I like it, I don't >>>> think we can do it, >>>> >? ? ? ? ?except if we >>>> >? ? ? ? ? >? ? ?do it >>>> >? ? ? ? ? >? ? ? >? ? ? > slightly differently: >>>> >? ? ? ? ? >? ? ? >? ? ? > I'm trying to solve two >>>> problems with one stone: >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- How to check for returns >>>> of JNI calls in >>>> >? ? ? ? ?the way that is >>>> >? ? ? ? ? >? ? ? >? ? ?done here >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- How to remove >>>> NSK_JNI_VERIFY* (from >>>> >? ? ? ? ? > ?nsk/share/jni/jni_tools) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > However, the NSK_JNI_VERIFY >>>> need to start a >>>> >? ? ? ? ?tracing system >>>> >? ? ? ? ? >? ? ?before >>>> >? ? ? ? ? >? ? ? >? ? ?the >>>> >? ? ? ? ? >? ? ? >? ? ? > call to JNI, so it won't work >>>> this way. (Side >>>> >? ? ? ? ?question >>>> >? ? ? ? ? >? ? ?would be >>>> >? ? ? ? ? >? ? ? >? ? ?do we >>>> >? ? ? ? ? >? ? ? >? ? ? > still care about the tracing >>>> in NSK_JNI_VERIFY, >>>> >? ? ? ? ?if we >>>> >? ? ? ? ? >? ? ?don't then >>>> >? ? ? ? ? >? ? ? >? ? ?your >>>> >? ? ? ? ? >? ? ? >? ? ? > solution works well in most >>>> situations). >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > My vision or intuition is >>>> that we would throw a >>>> >? ? ? ? ?template >>>> >? ? ? ? ? >? ? ?at some >>>> >? ? ? ? ? >? ? ? >? ? ?point >>>> >? ? ? ? ? >? ? ? >? ? ? > on SafeJNIEnv to handle both >>>> cases and have >>>> >? ? ? ? ?JNIVerifier >>>> >? ? ? ? ? >? ? ?become a >>>> >? ? ? ? ? >? ? ? >? ? ? > specialization in certain >>>> cases and something >>>> >? ? ? ? ?different >>>> >? ? ? ? ? >? ? ?for the >>>> >? ? ? ? ? >? ? ? >? ? ? > NSK_JNI_VERIFY case (or have >>>> a different >>>> >? ? ? ? ?constructor to enable >>>> >? ? ? ? ? >? ? ? >? ? ?tracing). >>>> >? ? ? ? ? >? ? ? >? ? ? > But for now, I offer the >>>> implementation that does: >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > jclass >>>> SafeJNIEnv::GetObjectClass(jobject obj) { >>>> >? ? ? ? ? >? ? ? >? ? ? > JNIVerifier marker(this, >>>> >? ? ? ? ?"GetObjectClass"); >>>> >? ? ? ? ? >? ? ? >? ? ? > return >>>> > ?marker.ResultNotNull(_jni_env->GetObjectClass(obj)); >>>> >? ? ? ? ? >? ? ? >? ? ? > } >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > and: >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > void >>>> SafeJNIEnv::SetObjectField(jobject obj, >>>> >? ? ? ? ?jfieldID >>>> >? ? ? ? ? >? ? ?field, jobject >>>> >? ? ? ? ? >? ? ? >? ? ? > value) { >>>> >? ? ? ? ? >? ? ? >? ? ? > JNIVerifier<> marker(this, >>>> "SetObjectField"); >>>> >? ? ? ? ? >? ? ? >? ? ? > _jni_env->SetObjectField(obj, >>>> field, value); >>>> >? ? ? ? ? >? ? ? >? ? ? > } >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- you added #include >>>> in the test >>>> >? ? ? ? ?(and you have to >>>> >? ? ? ? ? >? ? ? >? ? ?add it to >>>> >? ? ? ? ? >? ? ? >? ? ? > ?every test). >>>> >? ? ? ? ? >? ? ? >? ? ? > ?It would be simpler to add >>>> the include to >>>> >? ? ? ? ? >? ? ?SafeJNIEnv.hpp and >>>> >? ? ? ? ? >? ? ? >? ? ?define >>>> >? ? ? ? ? >? ? ? >? ? ? > ?typedef >>>> std::unique_ptr >>>> >? ? ? ? ?SafeJNIEnvPtr; >>>> >? ? ? ? ? >? ? ? >? ? ? > ?Then each in the test methods: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?SafeJNIEnvPtr env(new >>>> SafeJNIEnv(jni_env)); >>>> >? ? ? ? ? >? ? ? >? ? ? > ?or you can add >>>> >? ? ? ? ? >? ? ? >? ? ? > ?static SafeJNIEnv::SafeJNIEnvPtr >>>> >? ? ? ? ?wrap(JNIEnv* jni_env, >>>> >? ? ? ? ? >? ? ? > ?ErrorHandler >>>> >? ? ? ? ? >? ? ? >? ? ? > ?errorHandler = fatalError) >>>> >? ? ? ? ? >? ? ? >? ? ? > ?and get >>>> >? ? ? ? ? >? ? ? >? ? ? > ? ? ?SafeJNIEnvPtr env = >>>> >? ? ? ? ?SafeJNIEnv::wrap(jni_env); >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > Done, I like that, even less >>>> code change to >>>> >? ? ? ? ?tests then. >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- it would be better to wrap >>>> internal classes >>>> >? ? ? ? ? >? ? ? > ?(FatalOnException) into >>>> >? ? ? ? ? >? ? ? >? ? ? > ?unnamed namespace - this >>>> helps to avoid >>>> >? ? ? ? ?conflicts with >>>> >? ? ? ? ? >? ? ?other >>>> >? ? ? ? ? >? ? ? >? ? ?classes) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?- >>>> FatalOnException::check_for_null(void* ptr) >>>> >? ? ? ? ? >? ? ? >? ? ? > ?should be >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> ?FatalOnException::check_for_null(const >>>> >? ? ? ? ?void* ptr) >>>> >? ? ? ? ? >? ? ? >? ? ? > ?And calling the method you >>>> don't need >>>> >? ? ? ? ?reinterpret_cast >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > Also done, it got renamed to >>>> ResultNotNull, is >>>> >? ? ? ? ?using a >>>> >? ? ? ? ? >? ? ?template >>>> >? ? ? ? ? >? ? ? >? ? ?now, but >>>> >? ? ? ? ? >? ? ? >? ? ? > agreed, that worked. >>>> >? ? ? ? ? >? ? ? >? ? ? > Thanks again for the review, >>>> >? ? ? ? ? >? ? ? >? ? ? > Jc >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?--alex >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ?On 09/18/2018 11:07, JC >>>> Beyler wrote: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Hi David, >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Thanks for the quick >>>> review and >>>> >? ? ? ? ?thoughts. I have >>>> >? ? ? ? ? >? ? ?now a new >>>> >? ? ? ? ? >? ? ? >? ? ? > ?version here >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > that addresses your comments: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Webrev: >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ >>>> >>>> > >>>> ? >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> > >>>> ?Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > I've also inlined my >>>> answers/comments. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > I've slowly >>>> started working on >>>> >? ? ? ? ?JDK-8191519 >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>>> >? ? ? ? ? > >>>> ?. >>>> >? ? ? ? ? >? ? ? >? ? ? > ?However before >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > starting to really >>>> refactor all >>>> >? ? ? ? ?the tests, I >>>> >? ? ? ? ? >? ? ? >? ? ?thought I'd >>>> >? ? ? ? ? >? ? ? >? ? ? > ?get a few >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > opinions.?I am >>>> working on >>>> >? ? ? ? ?internalizing the >>>> >? ? ? ? ? >? ? ?error >>>> >? ? ? ? ? >? ? ? >? ? ?handling >>>> >? ? ? ? ? >? ? ? >? ? ? > ?of JNI >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?calls >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > via a SafeJNIEnv >>>> class that >>>> >? ? ? ? ?redefines all >>>> >? ? ? ? ? >? ? ?the JNI >>>> >? ? ? ? ? >? ? ? >? ? ?calls to >>>> >? ? ? ? ? >? ? ? >? ? ? > ?add an >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?error >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > checker. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > The advantage is >>>> that the test >>>> >? ? ? ? ?code will >>>> >? ? ? ? ? >? ? ?look and >>>> >? ? ? ? ? >? ? ? >? ? ?feel like >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?normal JNI >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > code and calls but >>>> will have the >>>> >? ? ? ? ?checks we >>>> >? ? ? ? ? >? ? ?want to have >>>> >? ? ? ? ? >? ? ? >? ? ? > ?for our >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?tests. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?Not sure I get that. >>>> Normal JNI code >>>> >? ? ? ? ?has to >>>> >? ? ? ? ? >? ? ?check for >>>> >? ? ? ? ? >? ? ? >? ? ? > ?errors/exceptions >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?after every call. The >>>> tests need >>>> >? ? ? ? ?those checks too. >>>> >? ? ? ? ? >? ? ? >? ? ?Today they are >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?explicit, with this >>>> change they become >>>> >? ? ? ? ? >? ? ?implicit. Not sure >>>> >? ? ? ? ? >? ? ? >? ? ? > ?what we are >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?gaining here ?? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > In my humble opinion, >>>> having the error >>>> >? ? ? ? ?checking out >>>> >? ? ? ? ? >? ? ?of the way >>>> >? ? ? ? ? >? ? ? >? ? ? > ?allows >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > the code reader to >>>> concentrate on the >>>> >? ? ? ? ?JNI code while >>>> >? ? ? ? ? >? ? ? > ?maintaining >>>> >? ? ? ? ? >? ? ? >? ? ? > ?error >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > checking. We use >>>> something similar >>>> >? ? ? ? ?internally, so >>>> >? ? ? ? ? >? ? ?perhaps I'm >>>> >? ? ? ? ? >? ? ? >? ? ? > ?biased to >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > it :-). >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > If this is not a >>>> desired/helpful >>>> >? ? ? ? ?"feature" to simplify >>>> >? ? ? ? ? >? ? ? >? ? ?tests in >>>> >? ? ? ? ? >? ? ? >? ? ? > ?general, >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > I will backtrack it and >>>> just add the >>>> >? ? ? ? ?explicit tests >>>> >? ? ? ? ? >? ? ?to the >>>> >? ? ? ? ? >? ? ? >? ? ?native >>>> >? ? ? ? ? >? ? ? >? ? ? > ?code >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > of the locks for the fix >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? > >>>> https://bugs.openjdk.java.net/browse/JDK-8191519?instead. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Let me however try to >>>> make my case and >>>> >? ? ? ? ?let me know what >>>> >? ? ? ? ? >? ? ? >? ? ?you all >>>> >? ? ? ? ? >? ? ? >? ? ? > ?think! >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > If agreed with >>>> this, we can >>>> >? ? ? ? ?augment the >>>> >? ? ? ? ? >? ? ?SafeJNIEnv >>>> >? ? ? ? ? >? ? ? >? ? ?class >>>> >? ? ? ? ? >? ? ? >? ? ? > ?as needed. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Also, if the tests >>>> require >>>> >? ? ? ? ?something else >>>> >? ? ? ? ? >? ? ?than fatal >>>> >? ? ? ? ? >? ? ? >? ? ? > ?errors, we >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?can add >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > a different marker >>>> and make it a >>>> >? ? ? ? ?parameter >>>> >? ? ? ? ? >? ? ?to the >>>> >? ? ? ? ? >? ? ? >? ? ?base class. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Webrev: >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.00/ >>>> >>>> > >>>> ? >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Bug: >>>> >? ? ? ? ? > >>>> https://bugs.openjdk.java.net/browse/JDK-8210842 >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Let me know what >>>> you think, >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?Two initial suggestions: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?1. FatalOnException >>>> should be >>>> >? ? ? ? ?constructed with a >>>> >? ? ? ? ? >? ? ? > ?description >>>> >? ? ? ? ? >? ? ? >? ? ? > ?string so >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?that it can report >>>> the failing >>>> >? ? ? ? ?operation when >>>> >? ? ? ? ? >? ? ?calling >>>> >? ? ? ? ? >? ? ? >? ? ? > ?FatalError rather >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?than the general >>>> "Problem with a JNI >>>> >? ? ? ? ?call". >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Agreed with you, the new >>>> webrev produces: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > FATAL ERROR in native >>>> method: GetObjectClass >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ?nsk.share.gc.lock.CriticalSectionTimedLocker.criticalSection(CriticalSectionTimedLocker.java:47) >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>>> >? ? ? ? ? >? ? ? >? ? ? > ?Method) >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ?nsk.share.gc.lock.CriticalSectionLocker$1.run(CriticalSectionLocker.java:56) >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> ?java.lang.Thread.run(java.base at 12-internal/Thread.java:834 >>>> ) >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > and for a return NULL in >>>> NewGlobalRef, >>>> >? ? ? ? ?we would get >>>> >? ? ? ? ? >? ? ? > ?automatically: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > FATAL ERROR in native method: >>>> >? ? ? ? ?NewGlobalRef:Return >>>> >? ? ? ? ? >? ? ?is NULL >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalNative(Native >>>> >? ? ? ? ? >? ? ? >? ? ? > ?Method) >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? ? ? at >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ?nsk.share.gc.lock.jniref.JNIGlobalRefLocker.criticalSection(JNIGlobalRefLocker.java:44) >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Again as we port and >>>> simplify more tests >>>> >? ? ? ? ?(I'll only >>>> >? ? ? ? ? >? ? ?do the >>>> >? ? ? ? ? >? ? ? >? ? ?locks >>>> >? ? ? ? ? >? ? ? >? ? ? > ?for now >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > and we can figure out the >>>> next steps as >>>> >? ? ? ? ?start >>>> >? ? ? ? ? >? ? ?working on >>>> >? ? ? ? ? >? ? ? >? ? ?moving >>>> >? ? ? ? ? >? ? ? >? ? ? > ?tests >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > out of vmTestbase), >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > we can add, if needed, >>>> other exception >>>> >? ? ? ? ?handlers >>>> >? ? ? ? ? >? ? ?that don't >>>> >? ? ? ? ? >? ? ? >? ? ?throw >>>> >? ? ? ? ? >? ? ? >? ? ? > ?or do >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > other things depending on >>>> the JNI method >>>> >? ? ? ? ?outputs. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?2. Make the local >>>> SafeJNIEnv a >>>> >? ? ? ? ?pointer called >>>> >? ? ? ? ? >? ? ?env so >>>> >? ? ? ? ? >? ? ? >? ? ?that the >>>> >? ? ? ? ? >? ? ? >? ? ? > ?change is >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?less disruptive. All >>>> the env->op() >>>> >? ? ? ? ?calls will >>>> >? ? ? ? ? >? ? ?remain >>>> >? ? ? ? ? >? ? ? >? ? ?and only >>>> >? ? ? ? ? >? ? ? >? ? ? > ?the local >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?error checking will >>>> be removed. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Done, I used a unique_ptr >>>> to make the object >>>> >? ? ? ? ? >? ? ? >? ? ? > ?created/destroyed/available >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > as a pointer do-able in >>>> one line: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> std::unique_ptr env(new >>>> >? ? ? ? ? > ?SafeJNIEnv(jni_env)); >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > and then you can see >>>> that, as you >>>> >? ? ? ? ?mentioned, the >>>> >? ? ? ? ? >? ? ?disruption to >>>> >? ? ? ? ? >? ? ? >? ? ? > ?the code >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > is much less: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.udiff.html >>>> >>>> > >>>> ? >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Basically the tests now >>>> become internal >>>> >? ? ? ? ?to the >>>> >? ? ? ? ? >? ? ?SafeJNIEnv >>>> >? ? ? ? ? >? ? ? >? ? ?and the >>>> >? ? ? ? ? >? ? ? >? ? ? > ?code >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > now only contains the JNI >>>> calls >>>> >? ? ? ? ?happening but we >>>> >? ? ? ? ? >? ? ?are protected >>>> >? ? ? ? ? >? ? ? >? ? ? > ?and will >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > fail any test that has an >>>> exception or a >>>> >? ? ? ? ?NULL >>>> >? ? ? ? ? >? ? ?return for the >>>> >? ? ? ? ? >? ? ? >? ? ? > ?call. Of >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > course, this is not 100% >>>> proof in terms >>>> >? ? ? ? ?of not >>>> >? ? ? ? ? >? ? ?having any >>>> >? ? ? ? ? >? ? ? >? ? ?error >>>> >? ? ? ? ? >? ? ? >? ? ? > ?handling >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > in the test but in some >>>> cases like this, >>>> >? ? ? ? ?the new >>>> >? ? ? ? ? >? ? ?code seems to >>>> >? ? ? ? ? >? ? ? >? ? ? > ?just work >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > better: >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp.html >>>> >>>> > >>>> ? >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> > >>>> ? >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?The switch from, >>>> e.g., checking NULL >>>> >? ? ? ? ?returns to >>>> >? ? ? ? ? >? ? ? >? ? ?checking for >>>> >? ? ? ? ? >? ? ? >? ? ? > ?pending >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?exceptions, need to >>>> be sure that the >>>> >? ? ? ? ?JNI operations >>>> >? ? ? ? ? >? ? ? >? ? ?clearly >>>> >? ? ? ? ? >? ? ? >? ? ? > ?specify >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?that >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?NULL implies there >>>> will be an exception >>>> >? ? ? ? ? >? ? ?pending. This >>>> >? ? ? ? ? >? ? ? >? ? ?change >>>> >? ? ? ? ? >? ? ? >? ? ? > ?may be an >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?issue for static code >>>> analysis if >>>> >? ? ? ? ?not smart >>>> >? ? ? ? ? >? ? ?enough to >>>> >? ? ? ? ? >? ? ? >? ? ? > ?understand the >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?RAII wrappers. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Agreed, I fixed it to be >>>> more strict and >>>> >? ? ? ? ?say: in >>>> >? ? ? ? ? >? ? ?normal test >>>> >? ? ? ? ? >? ? ? >? ? ? > ?handling, >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > the JNI calls should >>>> never return NULL >>>> >? ? ? ? ?or throw an >>>> >? ? ? ? ? >? ? ? > ?exception. This >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > should hold for tests I >>>> imagine but if >>>> >? ? ? ? ?not we can add a >>>> >? ? ? ? ? >? ? ? >? ? ?different >>>> >? ? ? ? ? >? ? ? >? ? ? > ?call >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > verifier as we go. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?Thanks, >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ?David >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? >? ? ? > Jc >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Let me know what you all >>>> think. When >>>> >? ? ? ? ?talking about it a >>>> >? ? ? ? ? >? ? ? >? ? ?bit, I had >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > gotten some interest to >>>> see what it >>>> >? ? ? ? ?would look >>>> >? ? ? ? ? >? ? ?like. Here >>>> >? ? ? ? ? >? ? ? >? ? ?it is >>>> >? ? ? ? ? >? ? ? >? ? ? > ?:-). Now >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > if it is not wanted like >>>> I said, I can >>>> >? ? ? ? ?backtrack >>>> >? ? ? ? ? >? ? ?and just >>>> >? ? ? ? ? >? ? ? >? ? ?put the >>>> >? ? ? ? ? >? ? ? >? ? ? > ?error >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > checks after each JNI >>>> call for all the >>>> >? ? ? ? ?tests as we are >>>> >? ? ? ? ? >? ? ? >? ? ?porting them. >>>> >? ? ? ? ? >? ? ? >? ? ? > ? > Jc >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? >? ? ? >? ? ? > -- >>>> >? ? ? ? ? >? ? ? >? ? ? > >>>> >? ? ? ? ? > >>>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> >> >> -- >> >> Thanks, >> Jc > From vladimir.kozlov at oracle.com Fri Sep 28 17:51:35 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Sep 2018 10:51:35 -0700 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> Message-ID: <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. Thanks, Vladimir On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: > Adding serviceability-dev at ... since this is JVM/TI... > > Dan > > > On 9/25/18 10:48 AM, Doug Simon wrote: >> A major design point of Graal is to treat allocations as non-side effecting to give more freedom >> to the optimizer by reducing the number of distinct FrameStates that need to be managed. When >> failing an allocation, Graal will deoptimize to the last side effecting instruction before the >> allocation. This mean the VM code for heap allocation will potentially be executed twice, once >> from Graal compiled code and then again in the interpreter. While this is perfectly fine according >> to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive >> 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event >> (on the Graal allocation slow path) might denote a bytecode instruction that performs no >> allocation, making it hard to debug the memory failure. >> >> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry >> points will attempt the allocation and upon failure, >> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled >> code using these entry points is expected deoptmize on null. >> >> The path from these new entry points to where allocation can fail goes through quite a bit of VM >> code. One could modify all these paths by: >> * Returning null instead of throwing an exception on failure. >> * Adding a `bool null_on_fail` argument to all relevant methods. >> * Adding extra null checking where necessary after each call to these methods when `null_on_fail >> == true`. >> This represents a significant number of changes. >> >> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, >> only the entry points and allocation routines that raise an exception need to be modified. Failure >> is communicated back to the new entry points by throwing a special pre-allocated OOME object >> (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of >> this object is not strictly necessary; it is introduced to highlight/document the special >> allocation mode. >> >> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >> >> -Doug > From alexey.menkov at oracle.com Fri Sep 28 18:04:48 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 28 Sep 2018 11:04:48 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <5BAE14DE.4040305@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> Message-ID: <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> Hi Gary, receiveReply(startPos, false, 0) calls waitForPrompt(startPos, compoundPromptOnly, count); and waitForPrompt has: if (count <= 0) { throw new TestBug("Wrong number of prompts count in Jdb.waitForPrompt(): " + count); } So We will get "Wrong number of prompts count" failure? --alex On 09/28/2018 04:47, Gary Adams wrote: > Revised webrev: > > ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ > > The final fix includes > ??? - updated the timeout for the test (should handle sparc debug > slowness) > ??? - wait for explicit prompts from cont command (avoids confusion > from "int[2]") > ??? - fixed a typo in an exclude pattern ("jdk.*") > ??? - on wait for message timeout, don't wait for prompt > ?????? when dumping current > > Should have another reviewer in addition to Chris. > > On 9/27/18, 3:12 PM, Chris Plummer wrote: >> The extra check after timing out doesn't seem like it should help. >> You've already called findMessage() 2100 times at 200ms intervals. Why >> would one more call after that help? I think it might be the >> receiveReply() call that is fixing it. It does a waitForPrompt(), so >> this probably gives us another 420000 ms for the prompt to come in. >> This call to receiveReply() is actually a bug itself since we are >> doing it just to print the current buffer, not the buffer after >> waiting for a prompt to come in. >> >> In any case, looks like this prompt is taking more than 420200 >> milliseconds to come in, but does eventually come in, and extra >> waiting in receiveReply() is what is causing you to eventually see the >> prompt. I think bumping up the timeout to 600 and the waittime to 10 >> is the proper fix here. >> >> And to address the receiveReply() issue, I'd suggest calling it using >> receiveReply(startPos, false, 0), where 0 is the prompt count, and >> have receiveReply() not wait for a prompt when the count is 0. >> >> Chris >> >> On 9/27/18 11:44 AM, Gary Adams wrote: >>> Speaking of not being bullet proof, during testing of the fix to >>> wait for a specific prompt an intermittent failure was observed. >>> ... >>> >>> Sending command: trace methods 0x2a9 >>> reply[0]: MyThread-0[1] >>> Sending command: cont >>> WARNING: message not recieved: MyThread-0[1] >>> Remaining debugger output follows: >>> reply[0]:> >>> reply[1]: Method exited: return value =, >>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>> line=93 bci=14 >>> reply[2]: 93??????? } >>> reply[3]: >>> reply[4]: MyThread-0[1] >>> # ERROR: Caught unexpected exception while executing the test: >>> nsk.share.Failure: Expected message not received during 420200 >>> milliseconds: >>> ... >>> >>> The wait for message times out looking for "MyThread-0[1]". >>> A WARNING is printed and the "remaining debugger output" >>> shows that "MyThread-0[1]" is in the buffer. >>> >>> I'm still investigating why the message match is not found. >>> >>> Adding a final check before failing the wait for message >>> seems to workaround the problem. >>> >>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>> @@ -515,10 +515,11 @@ >>> ???????? long delta = 200; // time in milliseconds to wait at every >>> iteration. >>> ???????? long total = 0;??? // total time has waited. >>> ???????? long max = >>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; // >>> maximum time to wait. >>> +??????? int found = 0; >>> >>> ???????? Object dummy = new Object(); >>> ???????? while ((total += delta) <= max) { >>> -??????????? int found = 0; >>> +??????????? found = 0; >>> >>> ???????????? // search for message >>> ???????????? { >>> @@ -553,6 +554,12 @@ >>> ???????? log.display("WARNING: message not recieved: " + message); >>> ???????? log.display("Remaining debugger output follows:"); >>> ???????? receiveReply(startPos); >>> + >>> +??????? // One last chance >>> +??????? found = findMessage(startPos, message); >>> +??????? if (found > 0) { >>> +??????????? return found; >>> +??????? } >>> ???????? throw new Failure("Expected message not received during " + >>> total + " milliseconds:" >>> ???????????????????????????? + "\n\t" + message); >>> ???? } >>> >>> >>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>> Looks good. Still not bullet proof, but I'm not sure it's possible >>>> to write tests like this in a way that will work no matter what >>>> output is produced by the method enter/exit events. >>>> >>>> Chris >>>> >>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>> The test failure has been identified due to the "int[2]" >>>>> being misrecognized as a compound prompt.? This caused a cont >>>>> command to be sent prematurely. >>>>> >>>>> The proposed fix waits for the correct prompt before >>>>> advancing to the next command. >>>>> >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>> >>>>> Testing is in progress. >>>> >>>> >>>> >>> >> >> > From chris.plummer at oracle.com Fri Sep 28 18:15:41 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 28 Sep 2018 11:15:41 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> Message-ID: <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> Yep. My suggestion was to use this version of receiveReply(), but also have receiveReply() not call waitForPrompt() if count was 0. I think it would be good to test with this change in place, but with a smaller timeout so you can reproduce the timeout error and test this receiveReply() call. Other than that the changes look fine to me. thanks, Chris On 9/28/18 11:04 AM, Alex Menkov wrote: > Hi Gary, > > receiveReply(startPos, false, 0) > calls > waitForPrompt(startPos, compoundPromptOnly, count); > > and waitForPrompt has: > ??????? if (count <= 0) { > ??????????? throw new TestBug("Wrong number of prompts count in > Jdb.waitForPrompt(): " + count); > ??????? } > > So We will get "Wrong number of prompts count" failure? > > --alex > > On 09/28/2018 04:47, Gary Adams wrote: >> Revised webrev: >> >> ?? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >> >> The final fix includes >> ???? - updated the timeout for the test (should handle sparc debug >> slowness) >> ???? - wait for explicit prompts from cont command (avoids confusion >> from "int[2]") >> ???? - fixed a typo in an exclude pattern ("jdk.*") >> ???? - on wait for message timeout, don't wait for prompt >> ??????? when dumping current >> >> Should have another reviewer in addition to Chris. >> >> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>> The extra check after timing out doesn't seem like it should help. >>> You've already called findMessage() 2100 times at 200ms intervals. >>> Why would one more call after that help? I think it might be the >>> receiveReply() call that is fixing it. It does a waitForPrompt(), so >>> this probably gives us another 420000 ms for the prompt to come in. >>> This call to receiveReply() is actually a bug itself since we are >>> doing it just to print the current buffer, not the buffer after >>> waiting for a prompt to come in. >>> >>> In any case, looks like this prompt is taking more than 420200 >>> milliseconds to come in, but does eventually come in, and extra >>> waiting in receiveReply() is what is causing you to eventually see >>> the prompt. I think bumping up the timeout to 600 and the waittime >>> to 10 is the proper fix here. >>> >>> And to address the receiveReply() issue, I'd suggest calling it >>> using receiveReply(startPos, false, 0), where 0 is the prompt count, >>> and have receiveReply() not wait for a prompt when the count is 0. >>> >>> Chris >>> >>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>> Speaking of not being bullet proof, during testing of the fix to >>>> wait for a specific prompt an intermittent failure was observed. >>>> ... >>>> >>>> Sending command: trace methods 0x2a9 >>>> reply[0]: MyThread-0[1] >>>> Sending command: cont >>>> WARNING: message not recieved: MyThread-0[1] >>>> Remaining debugger output follows: >>>> reply[0]:> >>>> reply[1]: Method exited: return value =, >>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>> line=93 bci=14 >>>> reply[2]: 93??????? } >>>> reply[3]: >>>> reply[4]: MyThread-0[1] >>>> # ERROR: Caught unexpected exception while executing the test: >>>> nsk.share.Failure: Expected message not received during 420200 >>>> milliseconds: >>>> ... >>>> >>>> The wait for message times out looking for "MyThread-0[1]". >>>> A WARNING is printed and the "remaining debugger output" >>>> shows that "MyThread-0[1]" is in the buffer. >>>> >>>> I'm still investigating why the message match is not found. >>>> >>>> Adding a final check before failing the wait for message >>>> seems to workaround the problem. >>>> >>>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>> @@ -515,10 +515,11 @@ >>>> ???????? long delta = 200; // time in milliseconds to wait at every >>>> iteration. >>>> ???????? long total = 0;??? // total time has waited. >>>> ???????? long max = >>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; // >>>> maximum time to wait. >>>> +??????? int found = 0; >>>> >>>> ???????? Object dummy = new Object(); >>>> ???????? while ((total += delta) <= max) { >>>> -??????????? int found = 0; >>>> +??????????? found = 0; >>>> >>>> ???????????? // search for message >>>> ???????????? { >>>> @@ -553,6 +554,12 @@ >>>> ???????? log.display("WARNING: message not recieved: " + message); >>>> ???????? log.display("Remaining debugger output follows:"); >>>> ???????? receiveReply(startPos); >>>> + >>>> +??????? // One last chance >>>> +??????? found = findMessage(startPos, message); >>>> +??????? if (found > 0) { >>>> +??????????? return found; >>>> +??????? } >>>> ???????? throw new Failure("Expected message not received during " >>>> + total + " milliseconds:" >>>> ???????????????????????????? + "\n\t" + message); >>>> ???? } >>>> >>>> >>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>> Looks good. Still not bullet proof, but I'm not sure it's possible >>>>> to write tests like this in a way that will work no matter what >>>>> output is produced by the method enter/exit events. >>>>> >>>>> Chris >>>>> >>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>> The test failure has been identified due to the "int[2]" >>>>>> being misrecognized as a compound prompt.? This caused a cont >>>>>> command to be sent prematurely. >>>>>> >>>>>> The proposed fix waits for the correct prompt before >>>>>> advancing to the next command. >>>>>> >>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>> >>>>>> Testing is in progress. >>>>> >>>>> >>>>> >>>> >>> >>> >> From gary.adams at oracle.com Fri Sep 28 18:20:39 2018 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 28 Sep 2018 14:20:39 -0400 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> Message-ID: <5BAE70F7.90108@oracle.com> I think I'd pref to just submit the exclude001 fix at this time without the Jdb.java changes. We can revisit this wait for message diagnostic clean up along with the kill002 fix. On 9/28/18, 2:15 PM, Chris Plummer wrote: > Yep. My suggestion was to use this version of receiveReply(), but also > have receiveReply() not call waitForPrompt() if count was 0. I think > it would be good to test with this change in place, but with a smaller > timeout so you can reproduce the timeout error and test this > receiveReply() call. Other than that the changes look fine to me. > > thanks, > > Chris > > On 9/28/18 11:04 AM, Alex Menkov wrote: >> Hi Gary, >> >> receiveReply(startPos, false, 0) >> calls >> waitForPrompt(startPos, compoundPromptOnly, count); >> >> and waitForPrompt has: >> if (count <= 0) { >> throw new TestBug("Wrong number of prompts count in >> Jdb.waitForPrompt(): " + count); >> } >> >> So We will get "Wrong number of prompts count" failure? >> >> --alex >> >> On 09/28/2018 04:47, Gary Adams wrote: >>> Revised webrev: >>> >>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >>> >>> The final fix includes >>> - updated the timeout for the test (should handle sparc debug >>> slowness) >>> - wait for explicit prompts from cont command (avoids confusion >>> from "int[2]") >>> - fixed a typo in an exclude pattern ("jdk.*") >>> - on wait for message timeout, don't wait for prompt >>> when dumping current >>> >>> Should have another reviewer in addition to Chris. >>> >>> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>>> The extra check after timing out doesn't seem like it should help. >>>> You've already called findMessage() 2100 times at 200ms intervals. >>>> Why would one more call after that help? I think it might be the >>>> receiveReply() call that is fixing it. It does a waitForPrompt(), >>>> so this probably gives us another 420000 ms for the prompt to come >>>> in. This call to receiveReply() is actually a bug itself since we >>>> are doing it just to print the current buffer, not the buffer after >>>> waiting for a prompt to come in. >>>> >>>> In any case, looks like this prompt is taking more than 420200 >>>> milliseconds to come in, but does eventually come in, and extra >>>> waiting in receiveReply() is what is causing you to eventually see >>>> the prompt. I think bumping up the timeout to 600 and the waittime >>>> to 10 is the proper fix here. >>>> >>>> And to address the receiveReply() issue, I'd suggest calling it >>>> using receiveReply(startPos, false, 0), where 0 is the prompt >>>> count, and have receiveReply() not wait for a prompt when the count >>>> is 0. >>>> >>>> Chris >>>> >>>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>>> Speaking of not being bullet proof, during testing of the fix to >>>>> wait for a specific prompt an intermittent failure was observed. >>>>> ... >>>>> >>>>> Sending command: trace methods 0x2a9 >>>>> reply[0]: MyThread-0[1] >>>>> Sending command: cont >>>>> WARNING: message not recieved: MyThread-0[1] >>>>> Remaining debugger output follows: >>>>> reply[0]:> >>>>> reply[1]: Method exited: return value =, >>>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>>> line=93 bci=14 >>>>> reply[2]: 93 } >>>>> reply[3]: >>>>> reply[4]: MyThread-0[1] >>>>> # ERROR: Caught unexpected exception while executing the test: >>>>> nsk.share.Failure: Expected message not received during 420200 >>>>> milliseconds: >>>>> ... >>>>> >>>>> The wait for message times out looking for "MyThread-0[1]". >>>>> A WARNING is printed and the "remaining debugger output" >>>>> shows that "MyThread-0[1]" is in the buffer. >>>>> >>>>> I'm still investigating why the message match is not found. >>>>> >>>>> Adding a final check before failing the wait for message >>>>> seems to workaround the problem. >>>>> >>>>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>> @@ -515,10 +515,11 @@ >>>>> long delta = 200; // time in milliseconds to wait at >>>>> every iteration. >>>>> long total = 0; // total time has waited. >>>>> long max = >>>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; >>>>> // maximum time to wait. >>>>> + int found = 0; >>>>> >>>>> Object dummy = new Object(); >>>>> while ((total += delta) <= max) { >>>>> - int found = 0; >>>>> + found = 0; >>>>> >>>>> // search for message >>>>> { >>>>> @@ -553,6 +554,12 @@ >>>>> log.display("WARNING: message not recieved: " + message); >>>>> log.display("Remaining debugger output follows:"); >>>>> receiveReply(startPos); >>>>> + >>>>> + // One last chance >>>>> + found = findMessage(startPos, message); >>>>> + if (found > 0) { >>>>> + return found; >>>>> + } >>>>> throw new Failure("Expected message not received during " >>>>> + total + " milliseconds:" >>>>> + "\n\t" + message); >>>>> } >>>>> >>>>> >>>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>>> Looks good. Still not bullet proof, but I'm not sure it's >>>>>> possible to write tests like this in a way that will work no >>>>>> matter what output is produced by the method enter/exit events. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>>> The test failure has been identified due to the "int[2]" >>>>>>> being misrecognized as a compound prompt. This caused a cont >>>>>>> command to be sent prematurely. >>>>>>> >>>>>>> The proposed fix waits for the correct prompt before >>>>>>> advancing to the next command. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>>> >>>>>>> Testing is in progress. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > From chris.plummer at oracle.com Fri Sep 28 18:23:48 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 28 Sep 2018 11:23:48 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <5BAE70F7.90108@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> <5BAE70F7.90108@oracle.com> Message-ID: I'm fine with keeping the Jdb changes out of this exclude001 fix, but I don't see what it has to do with kill002. IIRC the bug with that test is that it is only waiting for the first of two prompts that come in, so sometimes it returns the reply too early. Chris On 9/28/18 11:20 AM, Gary Adams wrote: > I think I'd pref to just submit the exclude001 fix at this time > without the > Jdb.java changes. > > We can revisit this wait for message diagnostic clean up along with > the kill002 > fix. > > On 9/28/18, 2:15 PM, Chris Plummer wrote: >> Yep. My suggestion was to use this version of receiveReply(), but >> also have receiveReply() not call waitForPrompt() if count was 0. I >> think it would be good to test with this change in place, but with a >> smaller timeout so you can reproduce the timeout error and test this >> receiveReply() call. Other than that the changes look fine to me. >> >> thanks, >> >> Chris >> >> On 9/28/18 11:04 AM, Alex Menkov wrote: >>> Hi Gary, >>> >>> receiveReply(startPos, false, 0) >>> calls >>> waitForPrompt(startPos, compoundPromptOnly, count); >>> >>> and waitForPrompt has: >>> ??????? if (count <= 0) { >>> ??????????? throw new TestBug("Wrong number of prompts count in >>> Jdb.waitForPrompt(): " + count); >>> ??????? } >>> >>> So We will get "Wrong number of prompts count" failure? >>> >>> --alex >>> >>> On 09/28/2018 04:47, Gary Adams wrote: >>>> Revised webrev: >>>> >>>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >>>> >>>> The final fix includes >>>> ???? - updated the timeout for the test (should handle sparc debug >>>> slowness) >>>> ???? - wait for explicit prompts from cont command (avoids >>>> confusion from "int[2]") >>>> ???? - fixed a typo in an exclude pattern ("jdk.*") >>>> ???? - on wait for message timeout, don't wait for prompt >>>> ??????? when dumping current >>>> >>>> Should have another reviewer in addition to Chris. >>>> >>>> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>>>> The extra check after timing out doesn't seem like it should help. >>>>> You've already called findMessage() 2100 times at 200ms intervals. >>>>> Why would one more call after that help? I think it might be the >>>>> receiveReply() call that is fixing it. It does a waitForPrompt(), >>>>> so this probably gives us another 420000 ms for the prompt to come >>>>> in. This call to receiveReply() is actually a bug itself since we >>>>> are doing it just to print the current buffer, not the buffer >>>>> after waiting for a prompt to come in. >>>>> >>>>> In any case, looks like this prompt is taking more than 420200 >>>>> milliseconds to come in, but does eventually come in, and extra >>>>> waiting in receiveReply() is what is causing you to eventually see >>>>> the prompt. I think bumping up the timeout to 600 and the waittime >>>>> to 10 is the proper fix here. >>>>> >>>>> And to address the receiveReply() issue, I'd suggest calling it >>>>> using receiveReply(startPos, false, 0), where 0 is the prompt >>>>> count, and have receiveReply() not wait for a prompt when the >>>>> count is 0. >>>>> >>>>> Chris >>>>> >>>>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>>>> Speaking of not being bullet proof, during testing of the fix to >>>>>> wait for a specific prompt an intermittent failure was observed. >>>>>> ... >>>>>> >>>>>> Sending command: trace methods 0x2a9 >>>>>> reply[0]: MyThread-0[1] >>>>>> Sending command: cont >>>>>> WARNING: message not recieved: MyThread-0[1] >>>>>> Remaining debugger output follows: >>>>>> reply[0]:> >>>>>> reply[1]: Method exited: return value =, >>>>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>>>> line=93 bci=14 >>>>>> reply[2]: 93??????? } >>>>>> reply[3]: >>>>>> reply[4]: MyThread-0[1] >>>>>> # ERROR: Caught unexpected exception while executing the test: >>>>>> nsk.share.Failure: Expected message not received during 420200 >>>>>> milliseconds: >>>>>> ... >>>>>> >>>>>> The wait for message times out looking for "MyThread-0[1]". >>>>>> A WARNING is printed and the "remaining debugger output" >>>>>> shows that "MyThread-0[1]" is in the buffer. >>>>>> >>>>>> I'm still investigating why the message match is not found. >>>>>> >>>>>> Adding a final check before failing the wait for message >>>>>> seems to workaround the problem. >>>>>> >>>>>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>> @@ -515,10 +515,11 @@ >>>>>> ???????? long delta = 200; // time in milliseconds to wait at >>>>>> every iteration. >>>>>> ???????? long total = 0;??? // total time has waited. >>>>>> ???????? long max = >>>>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; >>>>>> // maximum time to wait. >>>>>> +??????? int found = 0; >>>>>> >>>>>> ???????? Object dummy = new Object(); >>>>>> ???????? while ((total += delta) <= max) { >>>>>> -??????????? int found = 0; >>>>>> +??????????? found = 0; >>>>>> >>>>>> ???????????? // search for message >>>>>> ???????????? { >>>>>> @@ -553,6 +554,12 @@ >>>>>> ???????? log.display("WARNING: message not recieved: " + message); >>>>>> ???????? log.display("Remaining debugger output follows:"); >>>>>> ???????? receiveReply(startPos); >>>>>> + >>>>>> +??????? // One last chance >>>>>> +??????? found = findMessage(startPos, message); >>>>>> +??????? if (found > 0) { >>>>>> +??????????? return found; >>>>>> +??????? } >>>>>> ???????? throw new Failure("Expected message not received during >>>>>> " + total + " milliseconds:" >>>>>> ???????????????????????????? + "\n\t" + message); >>>>>> ???? } >>>>>> >>>>>> >>>>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>>>> Looks good. Still not bullet proof, but I'm not sure it's >>>>>>> possible to write tests like this in a way that will work no >>>>>>> matter what output is produced by the method enter/exit events. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>>>> The test failure has been identified due to the "int[2]" >>>>>>>> being misrecognized as a compound prompt.? This caused a cont >>>>>>>> command to be sent prematurely. >>>>>>>> >>>>>>>> The proposed fix waits for the correct prompt before >>>>>>>> advancing to the next command. >>>>>>>> >>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>>>> >>>>>>>> Testing is in progress. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >> >> > From gary.adams at oracle.com Fri Sep 28 18:29:25 2018 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 28 Sep 2018 14:29:25 -0400 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> <5BAE70F7.90108@oracle.com> Message-ID: <5BAE7305.50602@oracle.com> The kill002 logs I saw returned after the matching message e.g. "xxx killed" When the pending output was dumped it included next prompt, but the next prompt was not returned. This could have been a similar situation to the exclude timeout, which then ended up doing a wait for prompt as part of gathering the pending output. On 9/28/18, 2:23 PM, Chris Plummer wrote: > I'm fine with keeping the Jdb changes out of this exclude001 fix, but > I don't see what it has to do with kill002. IIRC the bug with that > test is that it is only waiting for the first of two prompts that come > in, so sometimes it returns the reply too early. > > Chris > > On 9/28/18 11:20 AM, Gary Adams wrote: >> I think I'd pref to just submit the exclude001 fix at this time >> without the >> Jdb.java changes. >> >> We can revisit this wait for message diagnostic clean up along with >> the kill002 >> fix. >> >> On 9/28/18, 2:15 PM, Chris Plummer wrote: >>> Yep. My suggestion was to use this version of receiveReply(), but >>> also have receiveReply() not call waitForPrompt() if count was 0. I >>> think it would be good to test with this change in place, but with a >>> smaller timeout so you can reproduce the timeout error and test this >>> receiveReply() call. Other than that the changes look fine to me. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/28/18 11:04 AM, Alex Menkov wrote: >>>> Hi Gary, >>>> >>>> receiveReply(startPos, false, 0) >>>> calls >>>> waitForPrompt(startPos, compoundPromptOnly, count); >>>> >>>> and waitForPrompt has: >>>> if (count <= 0) { >>>> throw new TestBug("Wrong number of prompts count in >>>> Jdb.waitForPrompt(): " + count); >>>> } >>>> >>>> So We will get "Wrong number of prompts count" failure? >>>> >>>> --alex >>>> >>>> On 09/28/2018 04:47, Gary Adams wrote: >>>>> Revised webrev: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >>>>> >>>>> The final fix includes >>>>> - updated the timeout for the test (should handle sparc debug >>>>> slowness) >>>>> - wait for explicit prompts from cont command (avoids >>>>> confusion from "int[2]") >>>>> - fixed a typo in an exclude pattern ("jdk.*") >>>>> - on wait for message timeout, don't wait for prompt >>>>> when dumping current >>>>> >>>>> Should have another reviewer in addition to Chris. >>>>> >>>>> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>>>>> The extra check after timing out doesn't seem like it should >>>>>> help. You've already called findMessage() 2100 times at 200ms >>>>>> intervals. Why would one more call after that help? I think it >>>>>> might be the receiveReply() call that is fixing it. It does a >>>>>> waitForPrompt(), so this probably gives us another 420000 ms for >>>>>> the prompt to come in. This call to receiveReply() is actually a >>>>>> bug itself since we are doing it just to print the current >>>>>> buffer, not the buffer after waiting for a prompt to come in. >>>>>> >>>>>> In any case, looks like this prompt is taking more than 420200 >>>>>> milliseconds to come in, but does eventually come in, and extra >>>>>> waiting in receiveReply() is what is causing you to eventually >>>>>> see the prompt. I think bumping up the timeout to 600 and the >>>>>> waittime to 10 is the proper fix here. >>>>>> >>>>>> And to address the receiveReply() issue, I'd suggest calling it >>>>>> using receiveReply(startPos, false, 0), where 0 is the prompt >>>>>> count, and have receiveReply() not wait for a prompt when the >>>>>> count is 0. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>>>>> Speaking of not being bullet proof, during testing of the fix to >>>>>>> wait for a specific prompt an intermittent failure was observed. >>>>>>> ... >>>>>>> >>>>>>> Sending command: trace methods 0x2a9 >>>>>>> reply[0]: MyThread-0[1] >>>>>>> Sending command: cont >>>>>>> WARNING: message not recieved: MyThread-0[1] >>>>>>> Remaining debugger output follows: >>>>>>> reply[0]:> >>>>>>> reply[1]: Method exited: return value =, >>>>>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>>>>> line=93 bci=14 >>>>>>> reply[2]: 93 } >>>>>>> reply[3]: >>>>>>> reply[4]: MyThread-0[1] >>>>>>> # ERROR: Caught unexpected exception while executing the test: >>>>>>> nsk.share.Failure: Expected message not received during 420200 >>>>>>> milliseconds: >>>>>>> ... >>>>>>> >>>>>>> The wait for message times out looking for "MyThread-0[1]". >>>>>>> A WARNING is printed and the "remaining debugger output" >>>>>>> shows that "MyThread-0[1]" is in the buffer. >>>>>>> >>>>>>> I'm still investigating why the message match is not found. >>>>>>> >>>>>>> Adding a final check before failing the wait for message >>>>>>> seems to workaround the problem. >>>>>>> >>>>>>> diff --git >>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> @@ -515,10 +515,11 @@ >>>>>>> long delta = 200; // time in milliseconds to wait at >>>>>>> every iteration. >>>>>>> long total = 0; // total time has waited. >>>>>>> long max = >>>>>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; >>>>>>> // maximum time to wait. >>>>>>> + int found = 0; >>>>>>> >>>>>>> Object dummy = new Object(); >>>>>>> while ((total += delta) <= max) { >>>>>>> - int found = 0; >>>>>>> + found = 0; >>>>>>> >>>>>>> // search for message >>>>>>> { >>>>>>> @@ -553,6 +554,12 @@ >>>>>>> log.display("WARNING: message not recieved: " + message); >>>>>>> log.display("Remaining debugger output follows:"); >>>>>>> receiveReply(startPos); >>>>>>> + >>>>>>> + // One last chance >>>>>>> + found = findMessage(startPos, message); >>>>>>> + if (found > 0) { >>>>>>> + return found; >>>>>>> + } >>>>>>> throw new Failure("Expected message not received during >>>>>>> " + total + " milliseconds:" >>>>>>> + "\n\t" + message); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>>>>> Looks good. Still not bullet proof, but I'm not sure it's >>>>>>>> possible to write tests like this in a way that will work no >>>>>>>> matter what output is produced by the method enter/exit events. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>>>>> The test failure has been identified due to the "int[2]" >>>>>>>>> being misrecognized as a compound prompt. This caused a cont >>>>>>>>> command to be sent prematurely. >>>>>>>>> >>>>>>>>> The proposed fix waits for the correct prompt before >>>>>>>>> advancing to the next command. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>>>>> >>>>>>>>> Testing is in progress. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > From gary.adams at oracle.com Fri Sep 28 18:35:48 2018 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 28 Sep 2018 14:35:48 -0400 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> <5BAE70F7.90108@oracle.com> Message-ID: <5BAE7484.6050001@oracle.com> Patch attached. On 9/28/18, 2:23 PM, Chris Plummer wrote: > I'm fine with keeping the Jdb changes out of this exclude001 fix, but > I don't see what it has to do with kill002. IIRC the bug with that > test is that it is only waiting for the first of two prompts that come > in, so sometimes it returns the reply too early. > > Chris > > On 9/28/18 11:20 AM, Gary Adams wrote: >> I think I'd pref to just submit the exclude001 fix at this time >> without the >> Jdb.java changes. >> >> We can revisit this wait for message diagnostic clean up along with >> the kill002 >> fix. >> >> On 9/28/18, 2:15 PM, Chris Plummer wrote: >>> Yep. My suggestion was to use this version of receiveReply(), but >>> also have receiveReply() not call waitForPrompt() if count was 0. I >>> think it would be good to test with this change in place, but with a >>> smaller timeout so you can reproduce the timeout error and test this >>> receiveReply() call. Other than that the changes look fine to me. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/28/18 11:04 AM, Alex Menkov wrote: >>>> Hi Gary, >>>> >>>> receiveReply(startPos, false, 0) >>>> calls >>>> waitForPrompt(startPos, compoundPromptOnly, count); >>>> >>>> and waitForPrompt has: >>>> if (count <= 0) { >>>> throw new TestBug("Wrong number of prompts count in >>>> Jdb.waitForPrompt(): " + count); >>>> } >>>> >>>> So We will get "Wrong number of prompts count" failure? >>>> >>>> --alex >>>> >>>> On 09/28/2018 04:47, Gary Adams wrote: >>>>> Revised webrev: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >>>>> >>>>> The final fix includes >>>>> - updated the timeout for the test (should handle sparc debug >>>>> slowness) >>>>> - wait for explicit prompts from cont command (avoids >>>>> confusion from "int[2]") >>>>> - fixed a typo in an exclude pattern ("jdk.*") >>>>> - on wait for message timeout, don't wait for prompt >>>>> when dumping current >>>>> >>>>> Should have another reviewer in addition to Chris. >>>>> >>>>> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>>>>> The extra check after timing out doesn't seem like it should >>>>>> help. You've already called findMessage() 2100 times at 200ms >>>>>> intervals. Why would one more call after that help? I think it >>>>>> might be the receiveReply() call that is fixing it. It does a >>>>>> waitForPrompt(), so this probably gives us another 420000 ms for >>>>>> the prompt to come in. This call to receiveReply() is actually a >>>>>> bug itself since we are doing it just to print the current >>>>>> buffer, not the buffer after waiting for a prompt to come in. >>>>>> >>>>>> In any case, looks like this prompt is taking more than 420200 >>>>>> milliseconds to come in, but does eventually come in, and extra >>>>>> waiting in receiveReply() is what is causing you to eventually >>>>>> see the prompt. I think bumping up the timeout to 600 and the >>>>>> waittime to 10 is the proper fix here. >>>>>> >>>>>> And to address the receiveReply() issue, I'd suggest calling it >>>>>> using receiveReply(startPos, false, 0), where 0 is the prompt >>>>>> count, and have receiveReply() not wait for a prompt when the >>>>>> count is 0. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>>>>> Speaking of not being bullet proof, during testing of the fix to >>>>>>> wait for a specific prompt an intermittent failure was observed. >>>>>>> ... >>>>>>> >>>>>>> Sending command: trace methods 0x2a9 >>>>>>> reply[0]: MyThread-0[1] >>>>>>> Sending command: cont >>>>>>> WARNING: message not recieved: MyThread-0[1] >>>>>>> Remaining debugger output follows: >>>>>>> reply[0]:> >>>>>>> reply[1]: Method exited: return value =, >>>>>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>>>>> line=93 bci=14 >>>>>>> reply[2]: 93 } >>>>>>> reply[3]: >>>>>>> reply[4]: MyThread-0[1] >>>>>>> # ERROR: Caught unexpected exception while executing the test: >>>>>>> nsk.share.Failure: Expected message not received during 420200 >>>>>>> milliseconds: >>>>>>> ... >>>>>>> >>>>>>> The wait for message times out looking for "MyThread-0[1]". >>>>>>> A WARNING is printed and the "remaining debugger output" >>>>>>> shows that "MyThread-0[1]" is in the buffer. >>>>>>> >>>>>>> I'm still investigating why the message match is not found. >>>>>>> >>>>>>> Adding a final check before failing the wait for message >>>>>>> seems to workaround the problem. >>>>>>> >>>>>>> diff --git >>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> @@ -515,10 +515,11 @@ >>>>>>> long delta = 200; // time in milliseconds to wait at >>>>>>> every iteration. >>>>>>> long total = 0; // total time has waited. >>>>>>> long max = >>>>>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; >>>>>>> // maximum time to wait. >>>>>>> + int found = 0; >>>>>>> >>>>>>> Object dummy = new Object(); >>>>>>> while ((total += delta) <= max) { >>>>>>> - int found = 0; >>>>>>> + found = 0; >>>>>>> >>>>>>> // search for message >>>>>>> { >>>>>>> @@ -553,6 +554,12 @@ >>>>>>> log.display("WARNING: message not recieved: " + message); >>>>>>> log.display("Remaining debugger output follows:"); >>>>>>> receiveReply(startPos); >>>>>>> + >>>>>>> + // One last chance >>>>>>> + found = findMessage(startPos, message); >>>>>>> + if (found > 0) { >>>>>>> + return found; >>>>>>> + } >>>>>>> throw new Failure("Expected message not received during >>>>>>> " + total + " milliseconds:" >>>>>>> + "\n\t" + message); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>>>>> Looks good. Still not bullet proof, but I'm not sure it's >>>>>>>> possible to write tests like this in a way that will work no >>>>>>>> matter what output is produced by the method enter/exit events. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>>>>> The test failure has been identified due to the "int[2]" >>>>>>>>> being misrecognized as a compound prompt. This caused a cont >>>>>>>>> command to be sent prematurely. >>>>>>>>> >>>>>>>>> The proposed fix waits for the correct prompt before >>>>>>>>> advancing to the next command. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>>>>> >>>>>>>>> Testing is in progress. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8208473.patch URL: From alexey.menkov at oracle.com Fri Sep 28 19:54:12 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 28 Sep 2018 12:54:12 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> <5BAE70F7.90108@oracle.com> Message-ID: +1 for exclude001 fix without the Jdb.java changes --alex On 09/28/2018 11:23, Chris Plummer wrote: > I'm fine with keeping the Jdb changes out of this exclude001 fix, but I > don't see what it has to do with kill002. IIRC the bug with that test is > that it is only waiting for the first of two prompts that come in, so > sometimes it returns the reply too early. > > Chris > > On 9/28/18 11:20 AM, Gary Adams wrote: >> I think I'd pref to just submit the exclude001 fix at this time >> without the >> Jdb.java changes. >> >> We can revisit this wait for message diagnostic clean up along with >> the kill002 >> fix. >> >> On 9/28/18, 2:15 PM, Chris Plummer wrote: >>> Yep. My suggestion was to use this version of receiveReply(), but >>> also have receiveReply() not call waitForPrompt() if count was 0. I >>> think it would be good to test with this change in place, but with a >>> smaller timeout so you can reproduce the timeout error and test this >>> receiveReply() call. Other than that the changes look fine to me. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/28/18 11:04 AM, Alex Menkov wrote: >>>> Hi Gary, >>>> >>>> receiveReply(startPos, false, 0) >>>> calls >>>> waitForPrompt(startPos, compoundPromptOnly, count); >>>> >>>> and waitForPrompt has: >>>> ??????? if (count <= 0) { >>>> ??????????? throw new TestBug("Wrong number of prompts count in >>>> Jdb.waitForPrompt(): " + count); >>>> ??????? } >>>> >>>> So We will get "Wrong number of prompts count" failure? >>>> >>>> --alex >>>> >>>> On 09/28/2018 04:47, Gary Adams wrote: >>>>> Revised webrev: >>>>> >>>>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >>>>> >>>>> The final fix includes >>>>> ???? - updated the timeout for the test (should handle sparc debug >>>>> slowness) >>>>> ???? - wait for explicit prompts from cont command (avoids >>>>> confusion from "int[2]") >>>>> ???? - fixed a typo in an exclude pattern ("jdk.*") >>>>> ???? - on wait for message timeout, don't wait for prompt >>>>> ??????? when dumping current >>>>> >>>>> Should have another reviewer in addition to Chris. >>>>> >>>>> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>>>>> The extra check after timing out doesn't seem like it should help. >>>>>> You've already called findMessage() 2100 times at 200ms intervals. >>>>>> Why would one more call after that help? I think it might be the >>>>>> receiveReply() call that is fixing it. It does a waitForPrompt(), >>>>>> so this probably gives us another 420000 ms for the prompt to come >>>>>> in. This call to receiveReply() is actually a bug itself since we >>>>>> are doing it just to print the current buffer, not the buffer >>>>>> after waiting for a prompt to come in. >>>>>> >>>>>> In any case, looks like this prompt is taking more than 420200 >>>>>> milliseconds to come in, but does eventually come in, and extra >>>>>> waiting in receiveReply() is what is causing you to eventually see >>>>>> the prompt. I think bumping up the timeout to 600 and the waittime >>>>>> to 10 is the proper fix here. >>>>>> >>>>>> And to address the receiveReply() issue, I'd suggest calling it >>>>>> using receiveReply(startPos, false, 0), where 0 is the prompt >>>>>> count, and have receiveReply() not wait for a prompt when the >>>>>> count is 0. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>>>>> Speaking of not being bullet proof, during testing of the fix to >>>>>>> wait for a specific prompt an intermittent failure was observed. >>>>>>> ... >>>>>>> >>>>>>> Sending command: trace methods 0x2a9 >>>>>>> reply[0]: MyThread-0[1] >>>>>>> Sending command: cont >>>>>>> WARNING: message not recieved: MyThread-0[1] >>>>>>> Remaining debugger output follows: >>>>>>> reply[0]:> >>>>>>> reply[1]: Method exited: return value =, >>>>>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>>>>> line=93 bci=14 >>>>>>> reply[2]: 93??????? } >>>>>>> reply[3]: >>>>>>> reply[4]: MyThread-0[1] >>>>>>> # ERROR: Caught unexpected exception while executing the test: >>>>>>> nsk.share.Failure: Expected message not received during 420200 >>>>>>> milliseconds: >>>>>>> ... >>>>>>> >>>>>>> The wait for message times out looking for "MyThread-0[1]". >>>>>>> A WARNING is printed and the "remaining debugger output" >>>>>>> shows that "MyThread-0[1]" is in the buffer. >>>>>>> >>>>>>> I'm still investigating why the message match is not found. >>>>>>> >>>>>>> Adding a final check before failing the wait for message >>>>>>> seems to workaround the problem. >>>>>>> >>>>>>> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>> @@ -515,10 +515,11 @@ >>>>>>> ???????? long delta = 200; // time in milliseconds to wait at >>>>>>> every iteration. >>>>>>> ???????? long total = 0;??? // total time has waited. >>>>>>> ???????? long max = >>>>>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * 1000; >>>>>>> // maximum time to wait. >>>>>>> +??????? int found = 0; >>>>>>> >>>>>>> ???????? Object dummy = new Object(); >>>>>>> ???????? while ((total += delta) <= max) { >>>>>>> -??????????? int found = 0; >>>>>>> +??????????? found = 0; >>>>>>> >>>>>>> ???????????? // search for message >>>>>>> ???????????? { >>>>>>> @@ -553,6 +554,12 @@ >>>>>>> ???????? log.display("WARNING: message not recieved: " + message); >>>>>>> ???????? log.display("Remaining debugger output follows:"); >>>>>>> ???????? receiveReply(startPos); >>>>>>> + >>>>>>> +??????? // One last chance >>>>>>> +??????? found = findMessage(startPos, message); >>>>>>> +??????? if (found > 0) { >>>>>>> +??????????? return found; >>>>>>> +??????? } >>>>>>> ???????? throw new Failure("Expected message not received during >>>>>>> " + total + " milliseconds:" >>>>>>> ???????????????????????????? + "\n\t" + message); >>>>>>> ???? } >>>>>>> >>>>>>> >>>>>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>>>>> Looks good. Still not bullet proof, but I'm not sure it's >>>>>>>> possible to write tests like this in a way that will work no >>>>>>>> matter what output is produced by the method enter/exit events. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>>>>> The test failure has been identified due to the "int[2]" >>>>>>>>> being misrecognized as a compound prompt.? This caused a cont >>>>>>>>> command to be sent prematurely. >>>>>>>>> >>>>>>>>> The proposed fix waits for the correct prompt before >>>>>>>>> advancing to the next command. >>>>>>>>> >>>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>>>>> >>>>>>>>> Testing is in progress. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > From jcbeyler at google.com Fri Sep 28 20:03:28 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 28 Sep 2018 13:03:28 -0700 Subject: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp In-Reply-To: <4b523285-e604-0cab-8c58-79aa5fa8731d@oracle.com> References: <48a98692-fa59-d445-de36-434220618e98@oracle.com> <1b3384b2-d64c-a2b7-949c-9da1ea73ee8c@oracle.com> <5d949adf-c36c-9bfe-cfda-8879746f0161@oracle.com> <0fea8a57-cd68-4fe0-6cc6-06ec2fdc3f63@oracle.com> <07A50333-EBF1-48DB-9FAC-678D914F936E@oracle.com> <05f50598-a193-908e-c645-17955b2dc451@oracle.com> <89c3cf25-dcfa-de2c-0971-ed09ddd9f518@oracle.com> <4b523285-e604-0cab-8c58-79aa5fa8731d@oracle.com> Message-ID: Thanks all for the reviews, I pushed the version webrev.05 and we can refactor and tweak the ExceptionCheckingJniEnv as we add more methods and look at more at how it is being used, Jc On Fri, Sep 28, 2018 at 10:30 AM Alex Menkov wrote: > +1 for webrev.05 > > --alex > > On 09/28/2018 04:25, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > > > I agree it can be refactored later so I'm Okay with the current webrev. > > > > Thanks, > > Serguei > > > > On 9/27/18 8:57 PM, JC Beyler wrote: > >> Hi Serguei, > >> > >> Exactly, I'm taking the lazy approach and just doing the ones I need. > >> Ideally I will find a better means to wrap around the methods without > >> having to redefine all of them but I've looked around and nothing > >> seems really perfect even with heavy utilization of C++ templates. > >> Perhaps I can use some macro definitions to make the code easier to be > >> generated but I did not want to go in either direction now, instead > >> preferring to keep it simple and direct. > >> > >> If you agree, as we add more methods we can always refactor this at > >> some point if someone (or us) finds a better solution to this but that > >> is an internal problem to the exception checking class and won't > >> affect the tests. > >> > >> Does that sound reasonable? > >> > >> Let me know, > >> Jc > >> > >> On Thu, Sep 27, 2018 at 8:00 PM >> > wrote: > >> > >> Hi Jc, > >> > >> Sorry for being late to the party. > >> The webrev5 looks good to me. > >> I don't think you have to try to fix the build system. > >> Avoiding using unique_ptr is good enough. > >> > >> Do I understand it right that the ExceptionCheckingJniEnv class > >> is going to enhanced with more JNI functions? > >> I'm wonder if it can be anyhow generalized to avoid this. > >> > >> Thanks, > >> Serguei > >> ** > >> > >> On 9/27/18 2:33 PM, JC Beyler wrote: > >>> Hi all, > >>> > >>> Sorry to come back to this so late in the game, but somehow when > >>> I synced my hg clone (or the issue was always there and it is a > >>> flaky build), it seems that something in the build might have > >>> changed? Basically now it seems that the build is adding flags > >>> that makes my usage of unique_ptr fail. > >>> > >>> I "think" it is due to the build adding the gnu++98 standard (But > >>> this has been there for a while it seems so most likely a > >>> side-effect is it is being now used): > >>> > >>> CXXSTD_CXXFLAG="-std=gnu++98" > >>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$CXXSTD_CXXFLAG > >>> -Werror], > >>> IF_FALSE: [CXXSTD_CXXFLAG=""]) > >>> > >>> (from: > >>> > https://hg.openjdk.java.net/jdk/jdk/file/dade6dd87bb4/make/autoconf/flags-cflags.m4 > ) > >>> but I'm not sure. > >>> > >>> When I remove that flag, my g++ goes to a more recent standard > >>> and unique_ptr works. > >>> > >>> So I now have to ask you all: > >>> 1) Should we try to fix the build system to at least have C++11 > >>> for the C++ tests, then my webrev.04 can stay as is but has to > >>> wait for that to happen > >>> 2) Should we push a new version that does not use unique_ptr? > >>> That solution would look like the following webrev: > >>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.05/ > >>> > >>> > >>> Sorry for the last minute rug pull, > >>> Jc > >>> > >>> On Thu, Sep 27, 2018 at 11:32 AM Mikael Vidstedt > >>> > > >>> wrote: > >>> > >>> > >>> Very, very nice! Thanks for adding the comment and renaming > >>> the class! Ship it! > >>> > >>> Cheers, > >>> Mikael > >>> > >>> > >>>> On Sep 27, 2018, at 10:45 AM, JC Beyler >>>> > wrote: > >>>> > >>>> Hi Mikael and David, > >>>> > >>>> @David: I thought it was implicit but did not want to > >>>> presume on this one because my goal is to start propagating > >>>> this new class in the test base and get the checks to be > >>>> done implicitly so I was probably being over-cautious > >>>> @Mikael: done and done, what do you think of the comment > >>>> here : > >>>> > http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.04/test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp.html > > > >>>> > >>>> For all, the new webrev is here: > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.04/ > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210842 > >>>> > >>>> Thanks, > >>>> Jc > >>>> > >>>> On Thu, Sep 27, 2018 at 6:03 AM David Holmes > >>>> > > >>>> wrote: > >>>> > >>>> Sorry Jc, I thought my LGTM was implicit. :) > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 26/09/2018 11:52 PM, JC Beyler wrote: > >>>> > Ping on this, anybody have time to do a review and > >>>> give a LGTM? Or David > >>>> > if you have time and will to provide an explicit LGTM :) > >>>> > > >>>> > Thanks, > >>>> > Jc > >>>> > > >>>> > On Mon, Sep 24, 2018 at 9:18 AM JC Beyler > >>>> > >>>> > >>>> >> wrote: > >>>> > > >>>> > Hi David, > >>>> > > >>>> > Sounds good to me, Alex gave me one LGTM, so it > >>>> seems I'm waiting > >>>> > for an explicit LGTM from you or from someone else > >>>> on this list to > >>>> > do a review. > >>>> > > >>>> > Thanks again for your help, > >>>> > Jc > >>>> > > >>>> > On Sun, Sep 23, 2018 at 9:22 AM David Holmes > >>>> > >>>> > >>>> >>>> >> wrote: > >>>> > > >>>> > Hi Jc, > >>>> > > >>>> > I don't think it is an issue for this to go > >>>> ahead. If the static > >>>> > analysis tool has an issue then we can either > >>>> find out how to > >>>> > teach it > >>>> > about this code structure, or else flag the > >>>> issues as false > >>>> > positives. > >>>> > I'd be relying on one of the serviceability > >>>> team here to handle > >>>> > that if > >>>> > the problem arises. > >>>> > > >>>> > Thanks, > >>>> > David > >>>> > > >>>> > On 23/09/2018 12:17 PM, JC Beyler wrote: > >>>> > > Hi David, > >>>> > > > >>>> > > No worries with the time to answer; I > >>>> appreciate the review! > >>>> > > > >>>> > > That's a fair point. Is it possible to > >>>> "describe" to the > >>>> > static analysis > >>>> > > tool to "trust" calls made in the > >>>> SafeJNIEnv class? > >>>> > > > >>>> > > Otherwise, do you have any idea on how to > >>>> go forward? For > >>>> > what it's > >>>> > > worth, this current webrev does not try to > >>>> replace exception > >>>> > checking > >>>> > > with the SafeJNIEnv (it actually adds it), > >>>> so for now the > >>>> > > question/solution could be delayed. I could > >>>> continue working > >>>> > on this in > >>>> > > the scope of both the nsk/gc/lock/jniref > >>>> code base and the > >>>> > NSK_VERIFIER > >>>> > > macro removal and we can look at how to > >>>> tackle the cases > >>>> > where the tests > >>>> > > are actually calling exception checking (I > >>>> know my > >>>> > heapmonitor does for > >>>> > > example). > >>>> > > > >>>> > > Let me know what you think and thanks for > >>>> the review, > >>>> > > Jc > >>>> > > > >>>> > > > >>>> > > On Sun, Sep 23, 2018 at 6:48 AM David Holmes > >>>> > >>>> > >>>> >>>> > > >>>> > > >>>> > >>>> > >>>> >>> wrote: > >>>> > > > >>>> > > Hi Jc, > >>>> > > > >>>> > > Sorry for the delay on getting back to > >>>> this but I'm > >>>> > travelling at the > >>>> > > moment. > >>>> > > > >>>> > > This looks quite neat. Thanks also to > >>>> Alex for all the > >>>> > suggestions. > >>>> > > > >>>> > > My only remaining concern is that > >>>> static analysis tools > >>>> > may not like > >>>> > > this because they may not be able to > >>>> determine that we > >>>> > won't make > >>>> > > subsequent JNI calls when an exception > >>>> happens in the > >>>> > first. That's not > >>>> > > a reason not to do this of course, just > >>>> flagging that we > >>>> > may have to do > >>>> > > something to deal with that problem. > >>>> > > > >>>> > > Thanks, > >>>> > > David > >>>> > > > >>>> > > On 20/09/2018 11:56 AM, JC Beyler wrote: > >>>> > > > Hi Alex, > >>>> > > > > >>>> > > > Done here, thanks for the review: > >>>> > > > > >>>> > > > Webrev: > >>>> > > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.03/ > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> > >>>> > > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> > >>>> > > > > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.03/> > >>>> > > > Bug: > >>>> https://bugs.openjdk.java.net/browse/JDK-8210842 > >>>> > > > > >>>> > > > Thanks again! > >>>> > > > Jc > >>>> > > > > >>>> > > > > >>>> > > > On Wed, Sep 19, 2018 at 5:13 PM Alex > >>>> Menkov > >>>> > > >>>> > >>>> > >>>> > > >>>> > >>>> > >>>> >>>> >> > >>>> > > > >>>> > >>>> > >>>> > > >>>> > > >>>> > >>>> > >>>> >>>> wrote: > >>>> > > > > >>>> > > > Hi Jc, > >>>> > > > > >>>> > > > Looks good to me. > >>>> > > > A minor note: > >>>> > > > - I'd move ErrorHandler typedef > >>>> to SafeJNIEnv > >>>> > class to avoid > >>>> > > global > >>>> > > > namespece pollution > >>>> (ErrorHandler is too generic > >>>> > name). > >>>> > > > > >>>> > > > --alex > >>>> > > > > >>>> > > > On 09/19/2018 15:56, JC Beyler > >>>> wrote: > >>>> > > > > Hi Alex, > >>>> > > > > > >>>> > > > > I've updated the webrev to: > >>>> > > > > Webrev: > >>>> > > > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.02/ > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> > >>>> > > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> > >>>> > > > > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> > >>>> > > > > > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.02/> > >>>> > > > > Bug: > >>>> > https://bugs.openjdk.java.net/browse/JDK-8210842 > >>>> > > > > > >>>> > > > > That webrev has the code that > >>>> is shown here in > >>>> > snippets. > >>>> > > > > > >>>> > > > > > >>>> > > > > Thanks for the reviews, I've > >>>> relatively > >>>> > followed your reviews > >>>> > > > except for > >>>> > > > > one detail due to me wanting > >>>> to handle the > >>>> > NSK_JNI_VERIFY > >>>> > > macros via > >>>> > > > > this system as well later > >>>> down the road. For an > >>>> > example: > >>>> > > > > > >>>> > > > > We currently have in the code: > >>>> > > > > if ( ! NSK_JNI_VERIFY(pEnv, > >>>> (mhClass = > >>>> > > NSK_CPP_STUB2(GetObjectClass, > >>>> > > > > pEnv, mhToCall)) != NULL) ) > >>>> > > > > > >>>> > > > > 1) The NSK_CPP_STUB2 is > >>>> trivially removed with > >>>> > a refactor > >>>> > > > (JDK-8210728) > >>>> > > > > > >>>> > > >>>> to: > >>>> > > > > if ( ! NSK_JNI_VERIFY(pEnv, > >>>> (mhClass = > >>>> > > pEnv->GetObjectClass(pEnv, > >>>> > > > > mhToCall)) != NULL) ) > >>>> > > > > > >>>> > > > > 2) Then the NSK_JNI_VERIFY, > >>>> I'd like to remove > >>>> > it to and it > >>>> > > > becomes via > >>>> > > > > this wrapping of JNIEnv: > >>>> > > > > if ( ! (mhClass = > >>>> pEnv->GetObjectClass(pEnv, > >>>> > mhToCall)) ) > >>>> > > > > > >>>> > > > > 3) Then, via removing the > >>>> assignment, we'd > >>>> > arrive to a: > >>>> > > > > mhClass = > >>>> pEnv->GetObjectClass(pEnv, mhToCall)); > >>>> > > > > if (!mhClass) > >>>> > > > > > >>>> > > > > Without any loss of checking > >>>> for failures, etc. > >>>> > > > > > >>>> > > > > So that is my motivation for > >>>> most of this work > >>>> > with a concrete > >>>> > > > example > >>>> > > > > (hopefully it helps drive > >>>> this conversation). > >>>> > > > > > >>>> > > > > I inlined my answers here, > >>>> let me know what you > >>>> > think. > >>>> > > > > > >>>> > > > > On Wed, Sep 19, 2018 at 2:30 > >>>> PM Alex Menkov > >>>> > > > >>>> > >>>> > >>>> > > >>>> > >>>> > >>>> >>>> >> > >>>> > > >>>> > >>>> > >>>> > > >>>> > >>>> > >>>> >>>> >>> > >>>> > > > > > >>>> >>>> > >>>> > >>>> > > >>>> > > >>>> > >>>> > >>>> >> > >>>> > > > >>>> > >>>> > >>>> > > >>>> > > >>>> > >>>> > >>>> >>>>> wrote: > >>>> > > > > > >>>> > > > > Hi Jc, > >>>> > > > > > >>>> > > > > Updated tests looks good. > >>>> > > > > Some notes about > implementation. > >>>> > > > > > >>>> > > > > - FatalOnException > >>>> implements both > >>>> > verification and error > >>>> > > > handling > >>>> > > > > It would be better to > >>>> separate them (and > >>>> > this makes > >>>> > > easy to > >>>> > > > implement > >>>> > > > > error handling different from > >>>> > JNIEnv::FatalError). > >>>> > > > > The simplest way is to > >>>> define error handler as > >>>> > > > > class SafeJNIEnv { > >>>> > > > > public: > >>>> > > > > typedef void > >>>> (*ErrorHandler)(JNIEnv > >>>> > *env, const > >>>> > > char* > >>>> > > > errorMsg); > >>>> > > > > // error handler which > >>>> terminates jvm > >>>> > by using > >>>> > > FatalError() > >>>> > > > > static void > >>>> FatalError(JNIEnv *env, > >>>> > const char > >>>> > > *errrorMsg); > >>>> > > > > > >>>> > > > > SafeJNIEnv(JNIEnv* > >>>> jni_env, ErrorHandler > >>>> > > errorHandler = > >>>> > > > > FatalError); > >>>> > > > > (SafeJNIEnv methods should > >>>> create > >>>> > FatalOnException objects > >>>> > > > passing > >>>> > > > > errorHandler) > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > Agreed, I tried to keep the > >>>> code simple. The > >>>> > concepts you > >>>> > > talk about > >>>> > > > > here are generally what I > >>>> reserve for when I > >>>> > need it (ie > >>>> > > > extensions and > >>>> > > > > handling new cases). But a > >>>> lot are going to be > >>>> > needed soon > >>>> > > so I > >>>> > > > think it > >>>> > > > > is a good time to iron the > >>>> code out now on this > >>>> > "simple" > >>>> > > webrev. > >>>> > > > > > >>>> > > > > So done for this. > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > - FatalOnException is used > >>>> in SafeJNIEnv > >>>> > methods as > >>>> > > > > FatalOnException > >>>> marker(this, "msg"); > >>>> > > > > ret = > >>>> > > > > > >>>> (optional)marker.check_for_null(ret); > >>>> > > > > return ret; > >>>> > > > > But actually I'd call it > >>>> something like > >>>> > > JNICallResultVerifier and > >>>> > > > > create > >>>> > > > > the object after JNI call. > like > >>>> > > > > ret = > >>>> > > > > > >>>> JNICallResultVerifier(this, "msg") > >>>> > > > > (optional).notNull(ret); > >>>> > > > > return ret; > >>>> > > > > or even (if you like such > >>>> syntax sugar) you > >>>> > can define > >>>> > > > > template > >>>> > > > > T resultNotNull(T result) > { > >>>> > > > > notNull(result); > >>>> > > > > return result; > >>>> > > > > } > >>>> > > > > and do > >>>> > > > > ret = > >>>> > > > > return > >>>> JNICallResultVerifier(this, > >>>> > > "msg").resultNotNull(ret); > >>>> > > > > > >>>> > > > > > >>>> > > > > So I renamed FatalOnException > >>>> to now being > >>>> > JNIVerifier. > >>>> > > > > > >>>> > > > > Though I like it, I don't > >>>> think we can do it, > >>>> > except if we > >>>> > > do it > >>>> > > > > slightly differently: > >>>> > > > > I'm trying to solve two > >>>> problems with one stone: > >>>> > > > > - How to check for returns > >>>> of JNI calls in > >>>> > the way that is > >>>> > > > done here > >>>> > > > > - How to remove > >>>> NSK_JNI_VERIFY* (from > >>>> > > nsk/share/jni/jni_tools) > >>>> > > > > > >>>> > > > > However, the NSK_JNI_VERIFY > >>>> need to start a > >>>> > tracing system > >>>> > > before > >>>> > > > the > >>>> > > > > call to JNI, so it won't work > >>>> this way. (Side > >>>> > question > >>>> > > would be > >>>> > > > do we > >>>> > > > > still care about the tracing > >>>> in NSK_JNI_VERIFY, > >>>> > if we > >>>> > > don't then > >>>> > > > your > >>>> > > > > solution works well in most > >>>> situations). > >>>> > > > > > >>>> > > > > My vision or intuition is > >>>> that we would throw a > >>>> > template > >>>> > > at some > >>>> > > > point > >>>> > > > > on SafeJNIEnv to handle both > >>>> cases and have > >>>> > JNIVerifier > >>>> > > become a > >>>> > > > > specialization in certain > >>>> cases and something > >>>> > different > >>>> > > for the > >>>> > > > > NSK_JNI_VERIFY case (or have > >>>> a different > >>>> > constructor to enable > >>>> > > > tracing). > >>>> > > > > But for now, I offer the > >>>> implementation that does: > >>>> > > > > > >>>> > > > > jclass > >>>> SafeJNIEnv::GetObjectClass(jobject obj) { > >>>> > > > > JNIVerifier > marker(this, > >>>> > "GetObjectClass"); > >>>> > > > > return > >>>> > marker.ResultNotNull(_jni_env->GetObjectClass(obj)); > >>>> > > > > } > >>>> > > > > > >>>> > > > > and: > >>>> > > > > > >>>> > > > > void > >>>> SafeJNIEnv::SetObjectField(jobject obj, > >>>> > jfieldID > >>>> > > field, jobject > >>>> > > > > value) { > >>>> > > > > JNIVerifier<> marker(this, > >>>> "SetObjectField"); > >>>> > > > > _jni_env->SetObjectField(obj, > >>>> field, value); > >>>> > > > > } > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > - you added #include > >>>> in the test > >>>> > (and you have to > >>>> > > > add it to > >>>> > > > > every test). > >>>> > > > > It would be simpler to add > >>>> the include to > >>>> > > SafeJNIEnv.hpp and > >>>> > > > define > >>>> > > > > typedef > >>>> std::unique_ptr > >>>> > SafeJNIEnvPtr; > >>>> > > > > Then each in the test methods: > >>>> > > > > SafeJNIEnvPtr env(new > >>>> SafeJNIEnv(jni_env)); > >>>> > > > > or you can add > >>>> > > > > static > SafeJNIEnv::SafeJNIEnvPtr > >>>> > wrap(JNIEnv* jni_env, > >>>> > > > ErrorHandler > >>>> > > > > errorHandler = fatalError) > >>>> > > > > and get > >>>> > > > > SafeJNIEnvPtr env = > >>>> > SafeJNIEnv::wrap(jni_env); > >>>> > > > > > >>>> > > > > > >>>> > > > > Done, I like that, even less > >>>> code change to > >>>> > tests then. > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > - it would be better to wrap > >>>> internal classes > >>>> > > > (FatalOnException) into > >>>> > > > > unnamed namespace - this > >>>> helps to avoid > >>>> > conflicts with > >>>> > > other > >>>> > > > classes) > >>>> > > > > > >>>> > > > > - > >>>> FatalOnException::check_for_null(void* ptr) > >>>> > > > > should be > >>>> > > > > > >>>> FatalOnException::check_for_null(const > >>>> > void* ptr) > >>>> > > > > And calling the method you > >>>> don't need > >>>> > reinterpret_cast > >>>> > > > > > >>>> > > > > > >>>> > > > > Also done, it got renamed to > >>>> ResultNotNull, is > >>>> > using a > >>>> > > template > >>>> > > > now, but > >>>> > > > > agreed, that worked. > >>>> > > > > Thanks again for the review, > >>>> > > > > Jc > >>>> > > > > > >>>> > > > > > >>>> > > > > --alex > >>>> > > > > > >>>> > > > > > >>>> > > > > On 09/18/2018 11:07, JC > >>>> Beyler wrote: > >>>> > > > > > Hi David, > >>>> > > > > > > >>>> > > > > > Thanks for the quick > >>>> review and > >>>> > thoughts. I have > >>>> > > now a new > >>>> > > > > version here > >>>> > > > > > that addresses your > comments: > >>>> > > > > > > >>>> > > > > > Webrev: > >>>> > > > > >>>> > > >>>> http://cr.openjdk.java.net/~jcbeyler/8210842/webrev.01/ > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > >>>> > > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > >>>> > > > > >>>> > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > >>>> > > > > > >>>> > > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > >>>> > > > > > > >>>> > > > >>>> < > http://cr.openjdk.java.net/%7Ejcbeyler/8210842/webrev.01/> > >>>> > > > > > > >>>> > > >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8210842 > >>>> > > > > > > >>>> > > > > > I've also inlined my > >>>> answers/comments. > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > I've slowly > >>>> started working on > >>>> > JDK-8191519 > >>>> > > > > > > > >>>> > > > >>>> . > >>>> > > > > However before > >>>> > > > > > > starting to really > >>>> refactor all > >>>> > the tests, I > >>>> > > > thought I'd > >>>> > > > > get a few > >>>> > > > > > > opinions. I am > >>>> working on > >>>> > internalizing the > >>>> > > error > >>>> > > > handling > >>>> > > > > of JNI > >>>> > > > > > calls > >>>> > > > > > > via a SafeJNIEnv > >>>> class that > >>>> > redefines all > >>>> > > the JNI > >>>> > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Sep 28 20:08:22 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 28 Sep 2018 13:08:22 -0700 Subject: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again In-Reply-To: <5BAE7305.50602@oracle.com> References: <5BA3DFFE.5090201@oracle.com> <5BAD2509.7020407@oracle.com> <5f86fe40-a734-f800-1997-1f10f2a8e8ae@oracle.com> <5BAE14DE.4040305@oracle.com> <7aeb6ee5-7eb4-8362-25e9-190f78f16baf@oracle.com> <0040680a-b381-68d0-dc9c-04c8c8b23fc4@oracle.com> <5BAE70F7.90108@oracle.com> <5BAE7305.50602@oracle.com> Message-ID: That's not quite the reason why kill002 failed. When doing a kill command, there are two prompts printed. One is printed immediately after issuing the async kill command, and the other after the async kill command completes. We first wait for the "killed" message, and then wait for the prompt. The problem is that waitForPrompt() is only waiting for the first prompt when it should wait for the second. Normally the second has already arrived with the "killed" output, but sometimes it doesn't, so we return with the second prompt still pending, and later the second prompt mistakenly shows up in the reply of the next command. https://bugs.openjdk.java.net/browse/JDK-8208473?focusedCommentId=14210269&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14210269 So we aren't dealing with a timeout in this case and we aren't dealing with receiveReply() being called for debug purposes and improperly waiting for the prompt. But there is a bit more going on than just this in the kill002 failure. After the last killed message is received (prematurely before the second prompt), the test does: ??????? reply = jdb.receiveReplyFor(JdbCommand.threads); ??????? reply = jdb.receiveReplyFor(JdbCommand.cont); The "threads" command returns early because of the arrival of the second prompt from the last "kill" command, which means the "threads" command also returns before its own prompt is received. It then does the "cont" command, which then itself terminates early because it receives the prompt belonging to the "threads" command. Then we move on to the following code, which has a bug in it: ??????? // make sure the debugger is at a breakpoint ??????? if (!jdb.isAtBreakpoint(reply, LAST_BREAK)) { ??????????? log.display("Expected breakpoint has not been hit yet"); ??????????? jdb.waitForMessage(0, LAST_BREAK); ??????? } ??????? log.display("Breakpoint has been hit"); The isAtBreakpoint() fails because the "cont" command has not actually completed yet. So we then do the waitForMessage() to wait for the breakpoint message. However, this code is buggy. It starts to look for LAST_BREAK starting from the very start of the stdout. It will find it immediately because it's there near the start of the log from when the breakpoint was setup: Sending command: stop in nsk.jdb.kill.kill002.kill002a.breakHere reply[0]: Set breakpoint nsk.jdb.kill.kill002.kill002a.breakHere reply[1]: main[1] So waitForMessage() does not do the job it was intended to do, and we move on to the next part of the test which is issuing the eval command. It fails to produce the proper output because the thread is not yet suspended at the breakpoint. The eval command output not only includes the indication of failure, it includes the simple prompt as proof that the thread was not suspended, and then also the breakpoint output, which should have arrived before the eval command was ever executed. Sending command: eval nsk.jdb.kill.kill002.kill002a.notKilled reply[0]: com.sun.tools.example.debug.expr.ParseException: Name unknown: nsk.jdb.kill.kill002.kill002a.notKilled reply[1]:? nsk.jdb.kill.kill002.kill002a.notKilled = null reply[2]: > reply[3]: Breakpoint hit: "thread=main", nsk.jdb.kill.kill002.kill002a.breakHere(), line=38 bci=0 reply[4]: 38??????? static void breakHere () {} reply[5]: reply[6]: main[1] So for kill002 we need to fix the handling of kill commands so they wait for the second prompt. I think once we do this, we no longer need the waitForMessage() error handling logic to wait for the breakpoint. We should be at the breakpoint after receiveReplyFor(JdbCommand.cont) returns, and we should just be verifying that we are there, not wait to get there. Chris On 9/28/18 11:29 AM, Gary Adams wrote: > The kill002 logs I saw returned after the matching message e.g. "xxx > killed" > When the pending output was dumped it included next prompt, > but the next prompt was not returned. This could have been a > similar situation to the exclude timeout, which then ended up > doing a wait for prompt as part of gathering the pending > output. > > On 9/28/18, 2:23 PM, Chris Plummer wrote: >> I'm fine with keeping the Jdb changes out of this exclude001 fix, but >> I don't see what it has to do with kill002. IIRC the bug with that >> test is that it is only waiting for the first of two prompts that >> come in, so sometimes it returns the reply too early. >> >> Chris >> >> On 9/28/18 11:20 AM, Gary Adams wrote: >>> I think I'd pref to just submit the exclude001 fix at this time >>> without the >>> Jdb.java changes. >>> >>> We can revisit this wait for message diagnostic clean up along with >>> the kill002 >>> fix. >>> >>> On 9/28/18, 2:15 PM, Chris Plummer wrote: >>>> Yep. My suggestion was to use this version of receiveReply(), but >>>> also have receiveReply() not call waitForPrompt() if count was 0. I >>>> think it would be good to test with this change in place, but with >>>> a smaller timeout so you can reproduce the timeout error and test >>>> this receiveReply() call. Other than that the changes look fine to me. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 9/28/18 11:04 AM, Alex Menkov wrote: >>>>> Hi Gary, >>>>> >>>>> receiveReply(startPos, false, 0) >>>>> calls >>>>> waitForPrompt(startPos, compoundPromptOnly, count); >>>>> >>>>> and waitForPrompt has: >>>>> ??????? if (count <= 0) { >>>>> ??????????? throw new TestBug("Wrong number of prompts count in >>>>> Jdb.waitForPrompt(): " + count); >>>>> ??????? } >>>>> >>>>> So We will get "Wrong number of prompts count" failure? >>>>> >>>>> --alex >>>>> >>>>> On 09/28/2018 04:47, Gary Adams wrote: >>>>>> Revised webrev: >>>>>> >>>>>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev.01/ >>>>>> >>>>>> The final fix includes >>>>>> ???? - updated the timeout for the test (should handle sparc >>>>>> debug slowness) >>>>>> ???? - wait for explicit prompts from cont command (avoids >>>>>> confusion from "int[2]") >>>>>> ???? - fixed a typo in an exclude pattern ("jdk.*") >>>>>> ???? - on wait for message timeout, don't wait for prompt >>>>>> ??????? when dumping current >>>>>> >>>>>> Should have another reviewer in addition to Chris. >>>>>> >>>>>> On 9/27/18, 3:12 PM, Chris Plummer wrote: >>>>>>> The extra check after timing out doesn't seem like it should >>>>>>> help. You've already called findMessage() 2100 times at 200ms >>>>>>> intervals. Why would one more call after that help? I think it >>>>>>> might be the receiveReply() call that is fixing it. It does a >>>>>>> waitForPrompt(), so this probably gives us another 420000 ms for >>>>>>> the prompt to come in. This call to receiveReply() is actually a >>>>>>> bug itself since we are doing it just to print the current >>>>>>> buffer, not the buffer after waiting for a prompt to come in. >>>>>>> >>>>>>> In any case, looks like this prompt is taking more than 420200 >>>>>>> milliseconds to come in, but does eventually come in, and extra >>>>>>> waiting in receiveReply() is what is causing you to eventually >>>>>>> see the prompt. I think bumping up the timeout to 600 and the >>>>>>> waittime to 10 is the proper fix here. >>>>>>> >>>>>>> And to address the receiveReply() issue, I'd suggest calling it >>>>>>> using receiveReply(startPos, false, 0), where 0 is the prompt >>>>>>> count, and have receiveReply() not wait for a prompt when the >>>>>>> count is 0. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/27/18 11:44 AM, Gary Adams wrote: >>>>>>>> Speaking of not being bullet proof, during testing of the fix to >>>>>>>> wait for a specific prompt an intermittent failure was observed. >>>>>>>> ... >>>>>>>> >>>>>>>> Sending command: trace methods 0x2a9 >>>>>>>> reply[0]: MyThread-0[1] >>>>>>>> Sending command: cont >>>>>>>> WARNING: message not recieved: MyThread-0[1] >>>>>>>> Remaining debugger output follows: >>>>>>>> reply[0]:> >>>>>>>> reply[1]: Method exited: return value =, >>>>>>>> "thread=MyThread-0", nsk.jdb.exclude.exclude001.MyThread.run(), >>>>>>>> line=93 bci=14 >>>>>>>> reply[2]: 93??????? } >>>>>>>> reply[3]: >>>>>>>> reply[4]: MyThread-0[1] >>>>>>>> # ERROR: Caught unexpected exception while executing the test: >>>>>>>> nsk.share.Failure: Expected message not received during 420200 >>>>>>>> milliseconds: >>>>>>>> ... >>>>>>>> >>>>>>>> The wait for message times out looking for "MyThread-0[1]". >>>>>>>> A WARNING is printed and the "remaining debugger output" >>>>>>>> shows that "MyThread-0[1]" is in the buffer. >>>>>>>> >>>>>>>> I'm still investigating why the message match is not found. >>>>>>>> >>>>>>>> Adding a final check before failing the wait for message >>>>>>>> seems to workaround the problem. >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java >>>>>>>> @@ -515,10 +515,11 @@ >>>>>>>> ???????? long delta = 200; // time in milliseconds to wait at >>>>>>>> every iteration. >>>>>>>> ???????? long total = 0;??? // total time has waited. >>>>>>>> ???????? long max = >>>>>>>> getLauncher().getJdbArgumentHandler().getWaitTime() * 60 * >>>>>>>> 1000; // maximum time to wait. >>>>>>>> +??????? int found = 0; >>>>>>>> >>>>>>>> ???????? Object dummy = new Object(); >>>>>>>> ???????? while ((total += delta) <= max) { >>>>>>>> -??????????? int found = 0; >>>>>>>> +??????????? found = 0; >>>>>>>> >>>>>>>> ???????????? // search for message >>>>>>>> ???????????? { >>>>>>>> @@ -553,6 +554,12 @@ >>>>>>>> ???????? log.display("WARNING: message not recieved: " + message); >>>>>>>> ???????? log.display("Remaining debugger output follows:"); >>>>>>>> ???????? receiveReply(startPos); >>>>>>>> + >>>>>>>> +??????? // One last chance >>>>>>>> +??????? found = findMessage(startPos, message); >>>>>>>> +??????? if (found > 0) { >>>>>>>> +??????????? return found; >>>>>>>> +??????? } >>>>>>>> ???????? throw new Failure("Expected message not received >>>>>>>> during " + total + " milliseconds:" >>>>>>>> ???????????????????????????? + "\n\t" + message); >>>>>>>> ???? } >>>>>>>> >>>>>>>> >>>>>>>> On 9/20/18, 5:47 PM, Chris Plummer wrote: >>>>>>>>> Looks good. Still not bullet proof, but I'm not sure it's >>>>>>>>> possible to write tests like this in a way that will work no >>>>>>>>> matter what output is produced by the method enter/exit events. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 9/20/18 10:59 AM, Gary Adams wrote: >>>>>>>>>> The test failure has been identified due to the "int[2]" >>>>>>>>>> being misrecognized as a compound prompt.? This caused a cont >>>>>>>>>> command to be sent prematurely. >>>>>>>>>> >>>>>>>>>> The proposed fix waits for the correct prompt before >>>>>>>>>> advancing to the next command. >>>>>>>>>> >>>>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8208473/webrev/ >>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8208473 >>>>>>>>>> >>>>>>>>>> Testing is in progress. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >> >> > From chris.plummer at oracle.com Fri Sep 28 20:17:51 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 28 Sep 2018 13:17:51 -0700 Subject: JDK-8203350: Crash in vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java In-Reply-To: <5BAE1BC1.5030405@oracle.com> References: <5BACCAB0.1050806@oracle.com> <5BAE1BC1.5030405@oracle.com> Message-ID: <33e4df93-2f6a-3eb6-aded-cb4c26f6fe0b@oracle.com> Hi Gary, If you haven't been able to reproduce the failure and just want to take it off the problemlist, I'm ok with that. I'd rather not see any test changes that could potentially hide the crash. If it eventually fails for some other reason and it can be shown that it is testbug due to improper classloading, then I can see adding the change you suggested. Chris On 9/28/18 5:17 AM, Gary Adams wrote: > At this point my first recommendation is to > simply remove the test from the ProblemList, > since it has not been reproduced after 1000s of > testruns with debug and release builds. > > What is not clear to me at the moment is - > was it intentional that hs201t001 intentionally placed > the classloader operation outside of doInit() and > hs201t002 placed the classloader operation in the > doInit() method. It appears that the primary > purpose of these two tests is the difference in behavior > for IsMethodObsolete. > > My best guess is that at some point the classloader operation > was failing after a RedefineClasses, and a workaround > was introduced into hs201t001. Later on the same > issue was observed with hs201t002, which did not have the > same workaround in place. > > My primary goal is to make the test reliable for > functionality it is intended to exercise. My secondary > goal is to have some consistency? between these > similar tests. > > From the discussions in the related issues, the > crashes were not able to be reproduced so the issues > were resolved as CNR. It was presumed that some other > fix accounted for the problem no longer being visible. > > On 9/27/18, 2:34 PM, Chris Plummer wrote: >> Hi Gary, >> >> Aren't you just hiding a potential jvmti bug with this change? If you >> think this is a test bug and this is a proper fix, I'd like to see an >> explanation of how the test is causing the crash. The explanation >> would need to involve native code, since pure java should never crash. >> >> thanks, >> >> Chris >> >> On 9/27/18 5:18 AM, Gary Adams wrote: >>> I've been unsuccessful trying to reproduce the failure in hs201t002. >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203350 >>> >>> Colleen made a comment on the bug that the reference >>> from hs201t002a to class hs201t002 might be an issue >>> for the redefined class. >>> >>> I found in test hs201t001 that an intentional reference >>> before entering hs201t001a.doInit() is made to avoid >>> that classloader operation. >>> >>> It's not clear to me why that was done, but the same workaround >>> could be used in hs201t002a, if it would make the test more robust. >>> >>> >>> diff --git >>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >>> >>> --- >>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >>> +++ >>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/newclass/hs201t002a.java >>> @@ -26,6 +26,7 @@ >>> ?public class hs201t002a extends Exception { >>> >>> ???? public hs201t002a () { >>> +??????? System.out.println("Current step: " + >>> hs201t002.currentStep); // Avoid calling classloader to find >>> hs201t002 in doInit() >>> ???????? doInit(); >>> ???? } >>> >> >> > From alexey.menkov at oracle.com Fri Sep 28 21:27:33 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 28 Sep 2018 14:27:33 -0700 Subject: RFR JDK-8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect Message-ID: <5f36b955-c7c4-73fb-3599-ae4eb66528d9@oracle.com> Hi all, please take a look ar a fix for https://bugs.openjdk.java.net/browse/JDK-8209332 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/CatchPattern/webrev.01/ The fix converts the test from shell to java and fixes ""ignore" command to match corresponding "catch" commands --alex From jcbeyler at google.com Fri Sep 28 22:18:42 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 28 Sep 2018 15:18:42 -0700 Subject: RFR JDK-8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect In-Reply-To: <5f36b955-c7c4-73fb-3599-ae4eb66528d9@oracle.com> References: <5f36b955-c7c4-73fb-3599-ae4eb66528d9@oracle.com> Message-ID: Hi Alex, Nice test fix and looks good to me, Jc On Fri, Sep 28, 2018 at 2:28 PM Alex Menkov wrote: > Hi all, > > please take a look ar a fix for > https://bugs.openjdk.java.net/browse/JDK-8209332 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/CatchPattern/webrev.01/ > > The fix converts the test from shell to java and fixes ""ignore" command > to match corresponding "catch" commands > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Sep 28 22:25:05 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 28 Sep 2018 15:25:05 -0700 Subject: RFR JDK-8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect In-Reply-To: <5f36b955-c7c4-73fb-3599-ae4eb66528d9@oracle.com> References: <5f36b955-c7c4-73fb-3599-ae4eb66528d9@oracle.com> Message-ID: <92420C80-8E3E-4227-BC4A-7F6EC2487EC4@oracle.com> Hi Alex, The fix looks good for me. Thanks. -Daniil ?On 9/28/18, 2:28 PM, "serviceability-dev on behalf of Alex Menkov" wrote: Hi all, please take a look ar a fix for https://bugs.openjdk.java.net/browse/JDK-8209332 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/CatchPattern/webrev.01/ The fix converts the test from shell to java and fixes ""ignore" command to match corresponding "catch" commands --alex From chris.plummer at oracle.com Sat Sep 29 01:56:32 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 28 Sep 2018 18:56:32 -0700 Subject: RFR JDK-8209332: [TEST] test/jdk/com/sun/jdi/CatchPatternTest.sh is incorrect In-Reply-To: <92420C80-8E3E-4227-BC4A-7F6EC2487EC4@oracle.com> References: <5f36b955-c7c4-73fb-3599-ae4eb66528d9@oracle.com> <92420C80-8E3E-4227-BC4A-7F6EC2487EC4@oracle.com> Message-ID: <7bffb343-e35e-5ab4-ac2a-f1bea27e5c32@oracle.com> +1 Chris On 9/28/18 3:25 PM, Daniil Titov wrote: > Hi Alex, > > The fix looks good for me. > > Thanks. > -Daniil > > > ?On 9/28/18, 2:28 PM, "serviceability-dev on behalf of Alex Menkov" wrote: > > Hi all, > > please take a look ar a fix for > https://bugs.openjdk.java.net/browse/JDK-8209332 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/CatchPattern/webrev.01/ > > The fix converts the test from shell to java and fixes ""ignore" command > to match corresponding "catch" commands > > --alex > > > From jcbeyler at google.com Sat Sep 29 02:44:39 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 28 Sep 2018 19:44:39 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: <2cd251ec-61df-b701-a9f2-a75efb2c732a@oracle.com> References: <2cd251ec-61df-b701-a9f2-a75efb2c732a@oracle.com> Message-ID: Hi Alex, Thanks for the review and nice catch. I updated my scripts and now fix that corner case. Here is the incremental webrev that fixes a few more white space issues: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00_01 Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 The full webrev is here: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 Let me know what you think, Jc On Fri, Sep 28, 2018 at 10:20 AM Alex Menkov wrote: > Hi Jc, > > Overall looks good. > Could you please update > ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp manually - > converted calls contain a lot of unnecessary spaces. > > --alex > > On 09/27/2018 22:15, JC Beyler wrote: > > Hi all, > > > > I continued the NSK_CPP_STUB removal with this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > > > This does the another set of 50 files of the jvmti subfolder, it is done > > automatically by the scripts I put in the bug comments. > > > > This passes the tests changed on my dev machine. > > > > Let me know what you think, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Sep 29 02:49:35 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 28 Sep 2018 19:49:35 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: References: Message-ID: <2521fc07-1ce2-dd35-1e6e-a5fbfe786888@oracle.com> Hi JC, In addition to Alex's ForceEarlyReturn001.cpp comment: There are many places where I see a space between two parens at the end of the line. For example, in attach020Agent00.cpp: ?168???? if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps)) ) { Every place NSK_JNI_VERIFY is used there is ugliness with "if" expressions involving JNI results that are not already boolean. Besides a boolean being computed for the JNI result, often there is also an assignment to the JNI result. I'm not sure if you have plans to clean stuff like this up, but it would be best to always do the assignment first, even if currently there is no local variable being assigned to. It would simplify the boolean expression being passed to NSK_JNI_VERIFY. Here's one example: ?137???? if (!NSK_JNI_VERIFY(jni, (array = (jbyteArray) ?138???????????? jni->GetStaticObjectField(cls, fieldID)) != NULL)) { This would be much better: ?137???? array = (jbyteArray)jni->GetStaticObjectField(cls, fieldID); ?138???? if (!NSK_JNI_VERIFY(jni, array != NULL) { attach015Target.cpp: use of ?: is not needed and it should be explicitly checking if FindClass is NULL. ? 40???? return jni->FindClass(LOADED_CLASS_NAME) ? JNI_TRUE : JNI_FALSE; attach022Agent00.cpp: The empty line 88 and 141 should be removed. Also extra space near the end of the line: thanks, Chris On 9/27/18 10:15 PM, JC Beyler wrote: > Hi all, > > I continued the NSK_CPP_STUB removal with this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > This does the another set of 50 files of the jvmti subfolder, it is > done automatically by the scripts I put in the bug comments. > > This passes the tests changed on my dev machine. > > Let me know what you think, > Jc