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

[Vladimir Kozlov]

Thank you, David and Martin

I added comment as David suggested and fixed incorrect exception 
messages (because HotSpotDiagnosticMXBean is not used in test):

http://cr.openjdk.java.net/~kvn/8202152/webrev.01/

Thanks,
Vladimir

On 4/24/18 1:22 AM, Doerr, Martin wrote:
> 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.
>>>>