RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Bradford Wetmore]

Just to followup, I've analyzed the whole PIT run.  The second one's 
call stack is identical to:

JDK-8067344: Adjust 
java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent 
changes in java.lang.invoke

So, really the only problem is the use of Asserts in your test case.

Brad

>>> Looks like you have a committer status, will you be pushing this?
>>
>> I can, yes. As soon as we clear-out the remaining questions, right?
>
> Yes.  The comments below are minor and shouldn't need another review
> cycle.  I have started a JPRT job for you, I'll run it through "core"
> target which will give us:
>
> jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*,
> jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools.
>
> Anything else?  I'm off tomorrow, I should have full results Wed.
>
> Here are the preliminary results for the jobs that have finished.
> jdk.testlibrary.Asserts is causing compilation errors, additional
> comments below:
>
> /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33:
> error: package jdk.testlibrary does not exist
> import static jdk.testlibrary.Asserts.*;
>                               ^
> /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52:
> error: cannot find symbol
>          assertEquals(bytes.length, nread, "short read");
>          ^
>    symbol:   method assertEquals(int,int,String)
>    location: class FileInputStreamPoolTest
> /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53:
> error: cannot find symbol
>          assertTrue(Arrays.equals(readBytes, bytes),
>          ^
>    symbol:   method assertTrue(boolean,String)
>    location: class FileInputStreamPoolTest
> 3 errors
>
> TEST RESULT: Failed. Compilation failed: Compilation failed
>
> I'm also getting failures in the following test.  I unfortunately have
> to leave now, so don't have time to look at this.  But it did mention
> "seed" so I'm mentioning it here.
>
> TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
>
> ACTION: main -- Failed. Execution failed: `main' threw exception:
> java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the
> same "-Dseed=" option as in the log file!
> REASON: User specified action: run main/othervm LFGarbageCollectedTest
> TIME:   213.406 seconds
> messages:
> command: main LFGarbageCollectedTest
> reason: User specified action: run main/othervm LFGarbageCollectedTest
> elapsed time (seconds): 213.406
> STDOUT:
> -Dseed=6102311124531075592
> -DtestLimit=2000
> Number of iterations according to -DtestLimit is 153 (1989 cases)
> Code cache size is 251658240 bytes
> Non-profiled code cache size is 123058253 bytes
> Number of iterations limited by code cache size is 84 (1092 cases)
> Number of iterations limited by non-profiled code cache size is 41 (533
> cases)
> Number of iterations is set to 41 (533 cases)
> Not enough time to continue execution. Interrupted.
> STDERR:
> Iteration 0:
> Tested LF caching feature with MethodHandles.foldArguments method.
> java.lang.AssertionError: Error: Lambda form is not garbage collected
>          at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81)
>          at
> LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139)
>          at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source)
>          at
> jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71)
>          at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201)
>          at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105)
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)