[11] RFR(XS) 8202152: test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails (original) (raw)

David Holmes david.holmes at oracle.com
Tue Apr 24 05:54:13 UTC 2018

To follow up ... Vladimir and I have had an interesting back and forth in the bug report. It seems that at least in some cases terminated threads are getting recycled - not just their pthread_t identities but the actual allocated stack region as well. We seem to end up with a new regular Java thread acquiring the id and stack of a just terminated compiler thread - hence the regular Java thread gets the wrong size stack!

This is quite bizarre and seems quite broken.

David

On 24/04/2018 7:24 AM, David Holmes wrote:

Hi Vladimir,

On 24/04/2018 5:20 AM, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8202152/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202152

After 8198756 changes compiler threads could be released and other Java threads can re-use the same HW threads for which stack size was determined during start. The test WBStackSize.java may fail in such cases because Java thread stack size is set and checked in test. That does not make sense to me. We don't "re-use HW threads" - I'm not even sure what that means. Compiler threads have a different stacksize to other Java threads - that seems simple enough. For 8198756 changes we added thread name check to workaround the problem [1]. But it seems is not enough. Why would this test be run in a compiler thread ???? To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to match Java thread stack size (note, size is in Kb for this flag). That seems like a workaround of the real problem. David ----- I also reverted changes in test code and instead added thread name print to know in case we still have problem in a future. Tier1 testing (which run the test) passed.

More information about the hotspot-dev mailing list