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

[Harold Seigel]

Thanks David!

I'll remove the call to parserThread.setDaemon(false).

Harold

On 5/31/2019 2:15 AM, David Holmes wrote:
> 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
>>