Re: 8218401: WRONG_PHASE: vmTestbase/nsk/jvmti test crash
Hi Daniil, I'd keep the volatile modifier for callbacksEnabled to disable compiler optimizations. Otherwise, looks good to me. Another approachcould be to disable event notifications in VMDeath callback with: SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_CLASS_LOAD, NULL); SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_BREAKPOINT, NULL); . . . Thanks, Serguei On 3/18/19 6:58 PM, Daniil Titov wrote: Hi Serguei and JC, Please review a new version of the fix that locks a monitor across the callbacks, as Serguei suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 Thanks! --Daniil On 3/18/19, 9:47 AM, "serguei.spit...@oracle.com" wrote: Hi Daniil, The JVMTI phase can change in the middle of callback work after the check you added. I'd suggest to lock a raw monitor across the callbacks to make them atomic. Thank you for taking care about this issue! Thanks, Serguei On 3/15/19 16:08, Daniil Titov wrote: > Please review the change that fixes 3 tests that intermittently fail with JVMTI_ERROR_WRONG_PHASE error. > > The problem here is that the callbacks these tests enable keep processing events and perform JVMTI calls after VM is terminated. The fix makes these test listen for VMDeath event and quick return from the callbacks after VMDeath event is received. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218401/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218401 > > Thanks! > -Daniil > >
Re: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out
The presence of the '-' sounds familiar. I recall reading about it in a review. I know I did a review for these tests that impacted the output, but I don't see it introducing a '-' anywhere. See JDK-8202466. However, that bug references JDK-8199519, which caused problems by changing a value in the output from a '-' to a 0: --- a/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java Wed Apr 25 17:50:32 2018 -0400 +++ b/test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCauseResults.java Thu Apr 26 09:45:47 2018 +0900 @@ -74,10 +74,18 @@ assertThat(GCT >= 0, "Incorrect time value for GCT"); assertThat(GCT >= YGCT, "GCT < YGCT (total garbage collection time < young generation garbage collection time)"); -int CGC = getIntValue("CGC"); -float CGCT = getFloatValue("CGCT"); -assertThat(CGCT >= 0, "Incorrect time value for CGCT"); +int CGC = 0; +float CGCT = 0.0f; +try { +CGC = getIntValue("CGC"); +} catch (NumberFormatException e) { +if (!e.getMessage().equals("Unparseable number: \"-\"")) { +throw e; +} +} if (CGC > 0) { +CGCT = getFloatValue("CGCT"); +assertThat(CGCT >= 0, "Incorrect time value for CGCT"); assertThat(CGCT > 0, "Number of concurrent GC events is " + CGC + ", but CGCT is 0"); } I'm not sure if any of this is related to what you are seeing. Chris On 3/19/19 11:39 AM, Gary Adams wrote: A quick follow up on the jstat test failures. On the failed runs the output looks like this : --messages:(3/127)-- command: shell jstatLineCounts4.sh reason: User specified action: run shell jstatLineCounts4.sh elapsed time (seconds): 7.496 --System.out:(13/1261)-- S0 S1 E O M CCSYGC YGCTFGCFGCTCGCCGCT GCT 0.00 0.00 0.00 0.00 - - 00.000 00.000 00.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 00.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 00.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 00.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 00.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 00.0000.000 0.00 0.00 0.00 0.00 - 28.19 10.571 00.000 00.0000.571 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 00.0000.571 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 00.0000.571 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 00.0000.571 S0 S1 E O M CCSYGC YGCTFGCFGCTCGCCGCT GCT 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 00.0000.571 The awk scripts used to check the output are not aware a dash '-' is allowed the metaspace column. Here is a quick stab to allow the dashes. Is anyone aware of recent changes in the gcutil output? diff --git a/test/jdk/sun/tools/jstat/lineCounts3.awk b/test/jdk/sun/tools/jstat/lineCounts3.awk --- a/test/jdk/sun/tools/jstat/lineCounts3.awk +++ b/test/jdk/sun/tools/jstat/lineCounts3.awk @@ -23,7 +23,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { datalines++; } diff --git a/test/jdk/sun/tools/jstat/lineCounts4.awk b/test/jdk/sun/tools/jstat/lineCounts4.awk --- a/test/jdk/sun/tools/jstat/lineCounts4.awk +++ b/test/jdk/sun/tools/jstat/lineCounts4.awk @@ -26,7 +26,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/ { +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[
Re: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out
Hi Gary, For the most part I think this fix is fine. However, you might want to file two followup bugs: 1. jtreg exclusiveAccess.dirs help text is incorrect. If it was correct, your fix would not work. 2. It's still not clear why these tests often don't play nice together. You suggested (offline) that it might have to do with the fact that two tests are trying to attach to each other at the same time, and this might be resulting in a deadlock. I would like to see a bug filed to eventually look into that. A stress test that spawns multiple tests that try to attach to each other should not be that hard write. I think all you need to do is exec() a bunch of jps processes. thanks, Chris On 3/19/19 5:22 AM, Gary Adams wrote: After 1000 testruns on {solaris,linux,windows,macosx} debug builds running test/jdk/sun/tools test/jdk/com/sun/tools/attach with this change, no failures were observed in TestJps or TempDirTest. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT +++ b/test/jdk/TEST.ROOT @@ -22,7 +22,11 @@ javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation java/lang/ProcessHandle # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote \ +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb sun/tools/jhsdb/heapconfig \ +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack sun/tools/jstat \ +com/sun/tools/attach sun/security/mscapi java/util/stream java/util/Arrays/largeMemory \ +java/util/BitSet/stream javax/rmi # Group definitions groups=TEST.groups Failures were observed in the following tests. sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts3.sh sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh sun/tools/jstatd/TestJstatdDefaults.java sun/tools/jstatd/TestJstatdServer.java sun/tools/jstatd/TestJstatdPort.java sun/tools/jstatd/TestJstatdExternalRegistry.java I'll investigate those failures some more, but I don't think they are related to the change to exclusiveAccess.dirs. Issues: https://bugs.openjdk.java.net/browse/JDK-8220295 https://bugs.openjdk.java.net/browse/JDK-8220242 At this point just looking for feedback, if this is a reasonable direction to deal with the intermittent timeouts with theses tests to reduce the concurrency with other attaching tests.
Re: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out
A quick follow up on the jstat test failures. On the failed runs the output looks like this : --messages:(3/127)-- command: shell jstatLineCounts4.sh reason: User specified action: run shell jstatLineCounts4.sh elapsed time (seconds): 7.496 --System.out:(13/1261)-- S0 S1 E O M CCSYGC YGCTFGCFGCTCGC CGCT GCT 0.00 0.00 0.00 0.00 - - 00.000 00.000 0 0.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 0 0.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 0 0.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 0 0.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 0 0.0000.000 0.00 0.00 0.00 0.00 - - 00.000 00.000 0 0.0000.000 0.00 0.00 0.00 0.00 - 28.19 10.571 00.000 0 0.0000.571 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 0 0.0000.571 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 0 0.0000.571 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 0 0.0000.571 S0 S1 E O M CCSYGC YGCTFGCFGCTCGC CGCT GCT 0.00 100.00 0.00 14.85 31.29 28.19 10.571 00.000 0 0.0000.571 The awk scripts used to check the output are not aware a dash '-' is allowed the metaspace column. Here is a quick stab to allow the dashes. Is anyone aware of recent changes in the gcutil output? diff --git a/test/jdk/sun/tools/jstat/lineCounts3.awk b/test/jdk/sun/tools/jstat/lineCounts3.awk --- a/test/jdk/sun/tools/jstat/lineCounts3.awk +++ b/test/jdk/sun/tools/jstat/lineCounts3.awk @@ -23,7 +23,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/{ +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/{ datalines++; } diff --git a/test/jdk/sun/tools/jstat/lineCounts4.awk b/test/jdk/sun/tools/jstat/lineCounts4.awk --- a/test/jdk/sun/tools/jstat/lineCounts4.awk +++ b/test/jdk/sun/tools/jstat/lineCounts4.awk @@ -26,7 +26,7 @@ headerlines++; } -/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/{ +/^[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+\.[0-9]+)|-[ ]*([0-9]+\.[0-9]+)|-[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+\.[0-9]+$/{ if (headerlines == 2) { datalines2++; } On 3/19/19, 8:22 AM, Gary Adams wrote: After 1000 testruns on {solaris,linux,windows,macosx} debug builds running test/jdk/sun/tools test/jdk/com/sun/tools/attach with this change, no failures were observed in TestJps or TempDirTest. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT +++ b/test/jdk/TEST.ROOT @@ -22,7 +22,11 @@ javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation java/lang/ProcessHandle # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote \ +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb sun/tools/jhsdb/heapconfig \ +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack sun/tools/jstat \ +com/sun/tools/attach sun/security/mscapi java/util/stream java/util/Arrays/largeMemory \ +java/util/BitSet/stream javax/rmi # Group definitions groups=TEST.groups Failures were observed in the following tests. sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts3.sh sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell],
Re: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability
Thanks Serguei! Thanks everyone for the code reviews. Coleen On 3/19/19 12:08 PM, serguei.spit...@oracle.com wrote: Hi Coleen, I'm Okay with this update. I did not know about the appcds tests using the runtime/RedefineTest test names. Thanks, Serguei On 3/19/19 07:25, coleen.phillim...@oracle.com wrote: On 3/19/19 10:02 AM, Daniel D. Daugherty wrote: On 3/19/19 7:39 AM, coleen.phillim...@oracle.com wrote: Sorry about this not being trivial after all. Two of the appcds tests had the old pathname in them: http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev test/hotspot/jtreg/TEST.groups No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java L27: * @summary Run /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to You need to update this path also. $ grep -r RedefineTests hotspot/jtreg/runtime/logging/RedefineClasses.java: * @comment This test is simplified version of runtime/RedefineTests/RedefineRunningMethods.java. hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java: * @summary Run /runtime/RedefineTest/RedefineRunningMethods in AppCDS mode to I fixed these in comments and summary too. Thanks! Coleen Did you grep for the old test names to make sure there are no other stale references? Dan Now tier1-3 pass. thanks, Coleen On 3/15/19 9:13 PM, serguei.spit...@oracle.com wrote: Hi Coleen, +1 Thank you for taking care about it! -Serguei On 3/15/19 5:42 PM, Chris Plummer wrote: +1 On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: Thumbs up. Dan On 3/15/19 8:25 PM, coleen.phillim...@oracle.com wrote: Hi, Okay I see how it works now. I was wondering how to tell it to ever run the tests. I fixed it so that the serviceability RedefineClasses tests are run in tier1 and I'll rerun tier1. http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev Coleen On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: Yikes. I missed that. Here's the beginning of tier1_runtime: L261: tier1_runtime = \ L262: runtime/ \ and here's the beginning of tier1_serviceability: L324 tier1_serviceability = \ L325 serviceability/dcmd/compiler \ I should not have assumed. Does anyone know why tier1_serviceability isn't "start with everything" and then "filter out some stuff"? Dan On 3/15/19 8:06 PM, Chris Plummer wrote: Hi Coleen, I think in TEST.groups you need to add serviceability/jvmti/RedefineClasses to tier1_serviceability. Otherwise the removes of specific tests isn't doing anything, and tier1_serviceability won't run the other tests you moved from tier1_runtime. thanks, Chris On 3/15/19 4:14 PM, coleen.phillim...@oracle.com wrote: Summary: move tests out of runtime to jvmti/RedefineClasses These always belonged in serviceability/jvmti. Also, moved a couple tests within serviceability/jvmti to RedefineClasses also. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220744 I ran these tests with make test TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and they passed. Tier1 testing is in progress. Thanks, Coleen
Re: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability
Hi Coleen, I'm Okay with this update. I did not know about the appcds tests using the runtime/RedefineTest test names. Thanks, Serguei On 3/19/19 07:25, coleen.phillim...@oracle.com wrote: On 3/19/19 10:02 AM, Daniel D. Daugherty wrote: On 3/19/19 7:39 AM, coleen.phillim...@oracle.com wrote: Sorry about this not being trivial after all. Two of the appcds tests had the old pathname in them: http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev test/hotspot/jtreg/TEST.groups No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java L27: * @summary Run /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to You need to update this path also. $ grep -r RedefineTests hotspot/jtreg/runtime/logging/RedefineClasses.java: * @comment This test is simplified version of runtime/RedefineTests/RedefineRunningMethods.java. hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java: * @summary Run /runtime/RedefineTest/RedefineRunningMethods in AppCDS mode to I fixed these in comments and summary too. Thanks! Coleen Did you grep for the old test names to make sure there are no other stale references? Dan Now tier1-3 pass. thanks, Coleen On 3/15/19 9:13 PM, serguei.spit...@oracle.com wrote: Hi Coleen, +1 Thank you for taking care about it! -Serguei On 3/15/19 5:42 PM, Chris Plummer wrote: +1 On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: Thumbs up. Dan On 3/15/19 8:25 PM, coleen.phillim...@oracle.com wrote: Hi, Okay I see how it works now. I was wondering how to tell it to ever run the tests. I fixed it so that the serviceability RedefineClasses tests are run in tier1 and I'll rerun tier1. http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev Coleen On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: Yikes. I missed that. Here's the beginning of tier1_runtime: L261: tier1_runtime = \ L262: runtime/ \ and here's the beginning of tier1_serviceability: L324 tier1_serviceability = \ L325 serviceability/dcmd/compiler \ I should not have assumed. Does anyone know why tier1_serviceability isn't "start with everything" and then "filter out some stuff"? Dan On 3/15/19 8:06 PM, Chris Plummer wrote: Hi Coleen, I think in TEST.groups you need to add serviceability/jvmti/RedefineClasses to tier1_serviceability. Otherwise the removes of specific tests isn't doing anything, and tier1_serviceability won't run the other tests you moved from tier1_runtime. thanks, Chris On 3/15/19 4:14 PM, coleen.phillim...@oracle.com wrote: Summary: move tests out of runtime to jvmti/RedefineClasses These always belonged in serviceability/jvmti. Also, moved a couple tests within serviceability/jvmti to RedefineClasses also. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220744 I ran these tests with make test TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and they passed. Tier1 testing is in progress. Thanks, Coleen
Re: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability
On 3/19/19 10:02 AM, Daniel D. Daugherty wrote: On 3/19/19 7:39 AM, coleen.phillim...@oracle.com wrote: Sorry about this not being trivial after all. Two of the appcds tests had the old pathname in them: http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev test/hotspot/jtreg/TEST.groups No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java L27: * @summary Run /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to You need to update this path also. $ grep -r RedefineTests hotspot/jtreg/runtime/logging/RedefineClasses.java: * @comment This test is simplified version of runtime/RedefineTests/RedefineRunningMethods.java. hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java: * @summary Run /runtime/RedefineTest/RedefineRunningMethods in AppCDS mode to I fixed these in comments and summary too. Thanks! Coleen Did you grep for the old test names to make sure there are no other stale references? Dan Now tier1-3 pass. thanks, Coleen On 3/15/19 9:13 PM, serguei.spit...@oracle.com wrote: Hi Coleen, +1 Thank you for taking care about it! -Serguei On 3/15/19 5:42 PM, Chris Plummer wrote: +1 On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: Thumbs up. Dan On 3/15/19 8:25 PM, coleen.phillim...@oracle.com wrote: Hi, Okay I see how it works now. I was wondering how to tell it to ever run the tests. I fixed it so that the serviceability RedefineClasses tests are run in tier1 and I'll rerun tier1. http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev Coleen On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: Yikes. I missed that. Here's the beginning of tier1_runtime: L261: tier1_runtime = \ L262: runtime/ \ and here's the beginning of tier1_serviceability: L324 tier1_serviceability = \ L325 serviceability/dcmd/compiler \ I should not have assumed. Does anyone know why tier1_serviceability isn't "start with everything" and then "filter out some stuff"? Dan On 3/15/19 8:06 PM, Chris Plummer wrote: Hi Coleen, I think in TEST.groups you need to add serviceability/jvmti/RedefineClasses to tier1_serviceability. Otherwise the removes of specific tests isn't doing anything, and tier1_serviceability won't run the other tests you moved from tier1_runtime. thanks, Chris On 3/15/19 4:14 PM, coleen.phillim...@oracle.com wrote: Summary: move tests out of runtime to jvmti/RedefineClasses These always belonged in serviceability/jvmti. Also, moved a couple tests within serviceability/jvmti to RedefineClasses also. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220744 I ran these tests with make test TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and they passed. Tier1 testing is in progress. Thanks, Coleen
Re: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability
On 3/19/19 7:39 AM, coleen.phillim...@oracle.com wrote: Sorry about this not being trivial after all. Two of the appcds tests had the old pathname in them: http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev test/hotspot/jtreg/TEST.groups No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java No comments. test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java L27: * @summary Run /runtime/RedefineTests/RedefineRunningMethods in AppCDS mode to You need to update this path also. Did you grep for the old test names to make sure there are no other stale references? Dan Now tier1-3 pass. thanks, Coleen On 3/15/19 9:13 PM, serguei.spit...@oracle.com wrote: Hi Coleen, +1 Thank you for taking care about it! -Serguei On 3/15/19 5:42 PM, Chris Plummer wrote: +1 On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: Thumbs up. Dan On 3/15/19 8:25 PM, coleen.phillim...@oracle.com wrote: Hi, Okay I see how it works now. I was wondering how to tell it to ever run the tests. I fixed it so that the serviceability RedefineClasses tests are run in tier1 and I'll rerun tier1. http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev Coleen On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: Yikes. I missed that. Here's the beginning of tier1_runtime: L261: tier1_runtime = \ L262: runtime/ \ and here's the beginning of tier1_serviceability: L324 tier1_serviceability = \ L325 serviceability/dcmd/compiler \ I should not have assumed. Does anyone know why tier1_serviceability isn't "start with everything" and then "filter out some stuff"? Dan On 3/15/19 8:06 PM, Chris Plummer wrote: Hi Coleen, I think in TEST.groups you need to add serviceability/jvmti/RedefineClasses to tier1_serviceability. Otherwise the removes of specific tests isn't doing anything, and tier1_serviceability won't run the other tests you moved from tier1_runtime. thanks, Chris On 3/15/19 4:14 PM, coleen.phillim...@oracle.com wrote: Summary: move tests out of runtime to jvmti/RedefineClasses These always belonged in serviceability/jvmti. Also, moved a couple tests within serviceability/jvmti to RedefineClasses also. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220744 I ran these tests with make test TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and they passed. Tier1 testing is in progress. Thanks, Coleen
RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out
After 1000 testruns on {solaris,linux,windows,macosx} debug builds running test/jdk/sun/tools test/jdk/com/sun/tools/attach with this change, no failures were observed in TestJps or TempDirTest. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT +++ b/test/jdk/TEST.ROOT @@ -22,7 +22,11 @@ javax/management sun/awt sun/java2d javax/xml/jaxp/testng/validation java/lang/ProcessHandle # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream java/util/Arrays/largeMemory java/util/BitSet/stream javax/rmi +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote \ +sun/tools/jstatd sun/tools/jcmd sun/tools/jhsdb sun/tools/jhsdb/heapconfig \ +sun/tools/jinfo sun/tools/jmap sun/tools/jps sun/tools/jstack sun/tools/jstat \ +com/sun/tools/attach sun/security/mscapi java/util/stream java/util/Arrays/largeMemory \ +java/util/BitSet/stream javax/rmi # Group definitions groups=TEST.groups Failures were observed in the following tests. sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts3.sh sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh,[],[solaris-sparcv9-debug],[ExitCode: 1],[bug4990825 shell], [jstatLineCounts4.sh],[37605],[] sun/tools/jstat/jstatLineCounts4.sh sun/tools/jstatd/TestJstatdDefaults.java sun/tools/jstatd/TestJstatdServer.java sun/tools/jstatd/TestJstatdPort.java sun/tools/jstatd/TestJstatdExternalRegistry.java I'll investigate those failures some more, but I don't think they are related to the change to exclusiveAccess.dirs. Issues: https://bugs.openjdk.java.net/browse/JDK-8220295 https://bugs.openjdk.java.net/browse/JDK-8220242 At this point just looking for feedback, if this is a reasonable direction to deal with the intermittent timeouts with theses tests to reduce the concurrency with other attaching tests.
Re: RFR (T) 8220744: Move RedefineTests to from runtime to serviceability
Sorry about this not being trivial after all. Two of the appcds tests had the old pathname in them: http://cr.openjdk.java.net/~coleenp/2019/8220744.03/webrev Now tier1-3 pass. thanks, Coleen On 3/15/19 9:13 PM, serguei.spit...@oracle.com wrote: Hi Coleen, +1 Thank you for taking care about it! -Serguei On 3/15/19 5:42 PM, Chris Plummer wrote: +1 On 3/15/19 5:29 PM, Daniel D. Daugherty wrote: Thumbs up. Dan On 3/15/19 8:25 PM, coleen.phillim...@oracle.com wrote: Hi, Okay I see how it works now. I was wondering how to tell it to ever run the tests. I fixed it so that the serviceability RedefineClasses tests are run in tier1 and I'll rerun tier1. http://cr.openjdk.java.net/~coleenp/2019/8220744.02/webrev Coleen On 3/15/19 8:14 PM, Daniel D. Daugherty wrote: Yikes. I missed that. Here's the beginning of tier1_runtime: L261: tier1_runtime = \ L262: runtime/ \ and here's the beginning of tier1_serviceability: L324 tier1_serviceability = \ L325 serviceability/dcmd/compiler \ I should not have assumed. Does anyone know why tier1_serviceability isn't "start with everything" and then "filter out some stuff"? Dan On 3/15/19 8:06 PM, Chris Plummer wrote: Hi Coleen, I think in TEST.groups you need to add serviceability/jvmti/RedefineClasses to tier1_serviceability. Otherwise the removes of specific tests isn't doing anything, and tier1_serviceability won't run the other tests you moved from tier1_runtime. thanks, Chris On 3/15/19 4:14 PM, coleen.phillim...@oracle.com wrote: Summary: move tests out of runtime to jvmti/RedefineClasses These always belonged in serviceability/jvmti. Also, moved a couple tests within serviceability/jvmti to RedefineClasses also. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8220744.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8220744 I ran these tests with make test TEST=open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses and they passed. Tier1 testing is in progress. Thanks, Coleen