RFR 8222671 : thread_large/thread_large.java times out on MacOSX
Igor Ignatyev
igor.ignatyev at oracle.com
Fri Aug 7 19:41:28 UTC 2020
> On Aug 6, 2020, at 12:33 AM, David Holmes <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