RFR 8222936: mlvm/anonloader/stress/randomBytecodes/Test.java fails due to "ERROR: There were 1 hangups during parsing."

David Holmes david.holmes at oracle.com
Fri May 31 06:15:51 UTC 2019


Hi Harold,

Seems a reasonable approach.

One nit:

!             parserThread.setDaemon(false);

false is the default so no need to set it explicitly.

Thanks,
David

On 31/05/2019 4:35 am, Harold Seigel wrote:
> Hi,
> 
> Please review this fix for bug JDK-8222936.
> 
> Test .../randomBytecodes/Test.java uses StressClassLoadingTest.java to 
> go through 1000's of iterations where it creates and starts a thread and 
> waits 10 seconds.  The thread tries to load a class whose bytes are 
> potentially randomized.  If the created thread is still alive after 10 
> seconds then the test saves the randomized class and records a hang 
> failure.  It then repeats the process for the next iteration.
> 
> This test fails about once a month with a hang failure.  These appear to 
> be invalid failures because the hangs cannot be reproduced with the 
> saved randomized class and because the stack traces of the hanging 
> threads are empty.  Perhaps it just took more than 10 seconds for the 
> thread to start because of lack of machine resources?
> 
> This change prevents the invalid failures by blocking the entire test 
> until either the test fails with a timeout or the loading thread 
> finishes, even if it takes more than 10 seconds.
> 
> Open Webrev: 
> http://cr.openjdk.java.net/~hseigel/bug_8222936/webrev/index.html
> 
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8222936
> 
> StressClassLoadingTest.java is used by three tests, 
> .../randomBytecodes/Test.java, .../byteMutation/Test.java, and 
> .../parallelLoad/Test.java.  The fix was tested by running the three 
> tests one thousand times on Linux x64 and a few times on Solaris, 
> Windows, and Mac OS X.
> 
> Thanks, Harold
> 


More information about the hotspot-runtime-dev mailing list