RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
Hi, This test times out under our automated testing configurations that include -Xcomp. Please review my change to increase the timeout for this test. It is sufficient for the test configurations in question to pass on two different local machines (Mac & Linux). diff -r 7c04ab31b4d6 test

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
On 5/1/17 12:50 PM, Mandy Chung wrote: On May 1, 2017, at 12:47 PM, Brent Christian wrote: >>> One refactor you can consider by separating them in several @run actions. The timeout will apply to each action but that does not help shorten the test execution time. I had the same thought, and

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
Hi, I have one more update, with a couple of suggested changes to simplify the execute() calls: * execute() takes a vararg, so explicit String[] creation can be omitted (mostly). * args common to every execute() call are consolidated into a List. (The resulting arg reordering should not af

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
On 5/1/17 12:41 PM, Mandy Chung wrote: Looks like this test execs a new VM for 66 times to exhaust the combination of with and without security manager, with a valid or malformed policy, client & custom loader in unnamed, named, automatic module. Right. I think we could take out the automatic

JEP-123: Configurable Secure Random-Number Generation

2017-05-18 Thread Milton Smith
Anyone, Wondering if anyone has information(link/docs) on how JEP-123 was implemented? Specifically, interested in the situation where the caller blocks on lack of entropy and how that was addressed. I took a look at the JEP-123 and JavaDocs but it’s not obvious to me. Following is related J

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
Hi, Joe The typical run time of this test is ~18s (on my modestly-equipped laptop). So the test does run within a reasonable amount of time, IMO - under normal circumstances, anyway. The increased timeout is to cover the less seldom test run configurations involving Xcomp. Judging by when

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
On 5/9/17 4:39 PM, Brent Christian wrote: On 5/9/17 4:27 PM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ Can it restore to the default timeout? Yes. Between the additional @runs and no longer testing automated modules, I believe that should be fine.

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
On 5/12/17 9:11 AM, Mandy Chung wrote: Minor comment: 95 private final List COMMON_ARGS; This is an instance field and you can use lower case as the convention. 238 return !s.equals(""); You can consider using String::isEmpty. Thanks, Mandy. I will make these cha

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
On 5/9/17 4:27 PM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ Thanks for the clean up. Does each @run action need 4 mins timeout? Can it restore to the default timeout? Yes. Between the additional @runs and no longer testing automated modules, I b

Re: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp

2017-05-18 Thread Brent Christian
Brent Christian wrote: > Mandy Chung wrote: >> >> I think we could take out the automatic module case as named module >> would verify it. One refactor you can consider by separating them >> in several @run actions. ... I think it would make the test easier to read and understand the cases it co