Hi Roger,
Looks good to me. If it were my own test I would add a little
Thread.sleep() after System.gc() to actually give time to the
gc to do something.
I have to note however that:
83 final long ERROR_PERCENT = 10;
84 final long ERROR_THRESHOLD = // 10% increase over min to
passing max
85 startHandles + ((startHandles + ERROR_PERCENT - 1)
/ ERROR_PERCENT);
is a bit misleading. IMO it only works because ERROR_PERCENT = 10; and
10 * 10 = 100; If you change it to ERROR_PERCENT = 1; for instance, then
you end up with allowing 100% of errors (and not 1%).
cheers,
-- daniel
On 11/03/2020 20:43, Roger Riggs wrote:
Please review a test improvement to avoid counting unexpected handles.
The test for 8239893[1]failed when non-test activities used handles.
The test is modified to do a warmup phase spawning some processes and
cleaning up.
It then runs the test to create processes looking for no significant
increase in handles.
The execution mode is limited to the interpreter to avoid potential side
effects of compilation.
The error condition was corrected to look only for increases in the
number of handles.
Previously, it looked for a 10% delta between the minimum and maximum
count of handles.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-handlecount-8240704/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8240704
Thanks, Roger
[1] 8239893 <https://bugs.openjdk.java.net/browse/JDK-8239893> Windows
handle Leak when starting processes using ProcessBuilder
