[11] RFR(XS) 8202152: test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
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