RFR 8222671 : thread_large/thread_large.java times out on MacOSX

[gerard ziemski]

Thank you David and Igor for the feedback!

I rewrote the test again, this time basing it off 
test/hotspot/jtreg/runtime/Thread/* tests.

For macOS and Linux we create threads until we hit a process limit 
thread count. Windows, however, allows unlimited (?) number of threads, 
though the process gradually slows down as the count grows, so I had to 
add time limit and I set it to 5 sec. I chose 5 sec because the value is 
well below jtreg time out (i.e. 120s), but still quite above how long my 
laptop needs to hit the process thread count limit (i.e. my Mac laptop 
needs about 1 sec to hit that limit).

Otherwise there are no other hardwired values or assumptions (I hope). 
What do you think of the test now?

bug link at https://bugs.openjdk.java.net/browse/JDK-8222671
open webrev at http://cr.openjdk.java.net/~gziemski/8222671_rev2
testing: Mach5 hs-tier1,2,3,4,5 in progress...




On 8/7/20 2:41 PM, Igor Ignatyev wrote:
>
>
>> On Aug 6, 2020, at 12:33 AM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Basing the new test around the existing thread stress tests was not 
>> unreasonable but I don't think we're actively adding to those tests. 
>> I would check with Igor whether it is better to just add this under 
>> runtime/thread rather than vmTestBase.
>
> Hi Gerard,
>
> David is right, we are trying to get rid of vmTestbase directory and 
> move all tests into corresponding component directories cleaning them 
> up at the same time. so runtime/thread directory sound like a much 
> better location for a new test.
>
> I don't think you need to cary all this baggage of 'VM testbase 
> keywords', 'converted from ...' and the rest, I'd suggest you just use 
> the text from 'DESCRIPTION' as @summary. I'd also remove System.exit 
> call and would just make thread009::run to return bool. it's also 
> unclear to me if someone is ever going to change THREADS_EXPECTED , 
> TIMEOUT, and DEBUG_MODE values, I'd just hardcode them in the test and 
> get rid of parsing. it seems that debug output won't clutter output, 
> so you might want to always print them and remove DEBUG_MODE field.
>
> using `assert` in test code isn't a good idea as it will work only if 
> someone runs test w/ `-ea` which not all people do. it's better to 
> replace w/ `if (p) throw new Error(...)`  or use jdk.test.lib.Asserts 
> class.
>
> Cheers,
> -- Igor