RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently
would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8201469 http://cr.openjdk.java.net/~mli/8201469/webrev.00/ ( For othervm.dirs property, I just reformat it. ) In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. I think stability of tests are more important than executing time, how do you think about it? Thank you -Hamlin
Re: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently
Is someone available to review the following patch? Thank you -Hamlin On 19/04/2018 4:17 PM, Hamlin Li wrote: would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8201469 http://cr.openjdk.java.net/~mli/8201469/webrev.00/ ( For othervm.dirs property, I just reformat it. ) In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. I think stability of tests are more important than executing time, how do you think about it? Thank you -Hamlin
Re: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently
Hi Hamlin, Do you have a sense of what rmi tests are problematic to run concurrently? Maybe you can subset to reduce the increased impact on execution time? Paul. > On Apr 20, 2018, at 12:21 AM, Hamlin Li wrote: > > Is someone available to review the following patch? > > Thank you > > -Hamlin > > > On 19/04/2018 4:17 PM, Hamlin Li wrote: >> would you please review the following patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8201469 >> >> http://cr.openjdk.java.net/~mli/8201469/webrev.00/ >> >> ( For othervm.dirs property, I just reformat it. ) >> >> >> In my test result, with jtreg option "-concurrency:4", after apply the >> patch, tier3 tests on different platforms will be slower about 1.5~2.0 times >> than before. >> I think stability of tests are more important than executing time, how do >> you think about it? >> >> Thank you >> -Hamlin >
Re: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently
Combining the reformatting and test additions makes the patch more difficult to review. The net effect seems to be adding the following directories to the exclusiveAccess.dirs list: 44 sun/management/jmxremote \ 45 sun/rmi \ 46 sun/security/mscapi \ 47 sun/tools/jstatd Is that correct? Please characterize the number of tests added to the list and the expected performance impact on the tier 3 test group. Thanks, -Joe On 4/23/2018 11:47 AM, Paul Sandoz wrote: Hi Hamlin, Do you have a sense of what rmi tests are problematic to run concurrently? Maybe you can subset to reduce the increased impact on execution time? Paul. On Apr 20, 2018, at 12:21 AM, Hamlin Li wrote: Is someone available to review the following patch? Thank you -Hamlin On 19/04/2018 4:17 PM, Hamlin Li wrote: would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8201469 http://cr.openjdk.java.net/~mli/8201469/webrev.00/ ( For othervm.dirs property, I just reformat it. ) In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. I think stability of tests are more important than executing time, how do you think about it? Thank you -Hamlin
Re: RFR of JDK-8201469,test under java/rmi should be restricted to not run concurrently
Hi Paul, Joe, Thank you for the comments. Following directories are added in the exclusiveAccess.dirs list: */ java/rmi (so, java/rmi/Naming is removed)/**/ /**/ com/sun/jndi/rmi/**/ /**/ sun/rmi/* for the test/bug number and time cost please check following table, here time cost is the number on my local machine. added directories test number run time subdirectories test number bug number java/rmi120 run time in -conc:4, 8:09 (14:15:16 - 14:07:07) run time in sequence, 18:17 (14:44:00 - 14:25:43) MarshalledObject 4 0 Naming 6 2 RMISecurityManager/checkPackageAccess 1 0 RemoteException/chaining1 0 activation 31 23 dgc 4 0 invalidName 1 0 module 1 0 registry9 1 reliability 3 2 server 45 7 transport 13 6 com/sun/jndi/rmi2 0 sun/rmi 17 run time in -conc:4, 00:44 (14:52:08 - 14:51:24) run time in sequence, 00:51 (14:48:10 - 14:47:19) 2 @Paul, Good suggestion, I tried to figure out a subset, but most of intermittent rmi test failures happen in java/rmi/[activation, server, transport, Naming, reliability, registry] and sun/rmi, they are almost all of rmi tests. I'm not sure if it's worth to subset them. I can do it if you think it's necessary. ( [1] lists rmi open issue in open area. ) Thank you -Hamlin [1] https://bugs.openjdk.java.net/issues/?jql=project%20%3D%20jdk%20and%20component%20%3D%20core-libs%20and%20Subcomponent%20%3D%20java.rmi%20and%20status%20in%20(open%2C%20new%2C%20%22In%20Progress%22)%20ORDER%20BY%20updatedDate%20DESC On 25/04/2018 12:14 PM, joe darcy wrote: Combining the reformatting and test additions makes the patch more difficult to review. The net effect seems to be adding the following directories to the exclusiveAccess.dirs list: 44 sun/management/jmxremote \ 45 sun/rmi \ 46 sun/security/mscapi \ 47 sun/tools/jstatd Is that correct? Please characterize the number of tests added to the list and the expected performance impact on the tier 3 test group. Thanks, -Joe On 4/23/2018 11:47 AM, Paul Sandoz wrote: Hi Hamlin, Do you have a sense of what rmi tests are problematic to run concurrently? Maybe you can subset to reduce the increased impact on execution time? Paul. On Apr 20, 2018, at 12:21 AM, Hamlin Li wrote: Is someone available to review the following patch? Thank you -Hamlin On 19/04/2018 4:17 PM, Hamlin Li wrote: would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8201469 http://cr.openjdk.java.net/~mli/8201469/webrev.00/ ( For othervm.dirs property, I just reformat it. ) In my test result, with jtreg option "-concurrency:4", after apply the patch, tier3 tests on different platforms will be slower about 1.5~2.0 times than before. I think stability of tests are more important than executing time, how do you think about it? Thank you -Hamlin
