[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