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