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

[dean.long at oracle.com]

It seems like this could still break if the pthreads implementation 
decides to hand out (non-recycled) threads with oversized stacks, or if 
there are recycled threads that don't use the values from the 
command-line.  What happens if we run lots of tests in samevm mode, and 
those tests uses different values for the stack size?  Then wouldn't 
pthreads have a cache of various stack sizes to recycle new threads from?

dl

On 4/23/18 11:12 PM, David Holmes wrote:
> 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.
>>>>