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

[Doerr, Martin]

Hi Vladimir,

looks good. Thanks for fixing.
The comment proposed by David would be nice, but I don't need to see a new webrev for that.

Best regards,
Martin


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Dienstag, 24. April 2018 08:12
To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: [11] RFR(XS) 8202152: test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails

On 24/04/2018 3:54 PM, David Holmes wrote:
> 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.

No it's not broken. The stacksize attribute is just a minimum size, so 
the OS can reuse a terminated thread with a larger stack - and that's 
what we are seeing.

So the fix is fine, I would just add before @run:

@comment Must use the same stacksize for Java threads and compiler 
threads in case of thread recycling

Or something to that affect.

Thanks,
David

> 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.
>>>