[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    RE: JVM inserting guard pages into stack of initial thread - will that stop with Java 10?
From:       "Doerr, Martin" <martin.doerr () sap ! com>
Date:       2017-10-24 10:59:59
Message-ID: 3ef4f6f626854d75a69bd908eaf01904 () sap ! com
[Download RAW message or body]

Hi Andrew,

thanks for your reply. I guess that the performance impact will be negligible if we \
have enough inlining (which reduces the number of stack checks). Reducing complexity \
and saving stack space sounds more valuable to me. I may consider making experiments \
when I find some time for it.

Best regards,
Martin


-----Original Message-----
From: Andrew Haley [mailto:aph@redhat.com] 
Sent: Dienstag, 24. Oktober 2017 11:24
To: Doerr, Martin <martin.doerr@sap.com>; Tomas Kalibera <tomas.kalibera@gmail.com>; \
                hotspot-runtime-dev@openjdk.java.net
Subject: Re: JVM inserting guard pages into stack of initial thread - will that stop \
with Java 10?

On 23/10/17 18:25, Doerr, Martin wrote:

> after reading several mails about guard page problems (and quite
> some own bad experience), I wonder if they are really worth all the
> pain. Is the performance benefit from stack banging so great, that
> it justifies the tremendous complexity?
> 
> If not, I'd vote for replacing them by explicit checks. Loading a
> limit from the Thread and performing a comparison doesn't sound so
> expensive.
> 
> It could be the case that some platforms need banging (e.g. Windows
> due to on demand committed stack), but probably not all.
> Am I missing anything?

I think you should try it and tell us the results.  If we have
power-of-2 stack sizes it can be done without any loads at all, but
that's probably too restrictive, and we've had quite enough
tricksiness.  It's hard to beat the speed of a simple store, though.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


[prev in list] [next in list] [prev in thread] [next in thread]