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

Doerr, Martin martin.doerr at sap.com
Tue Apr 24 08:22:41 UTC 2018

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

More information about the hotspot-dev mailing list