RFR 8222671 : thread_large/thread_large.java times out on MacOSX
gerard ziemski
gerard.ziemski at oracle.com
Mon Aug 17 15:28:43 UTC 2020
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
More information about the hotspot-runtime-dev
mailing list