RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8]

David Holmes david.holmes at oracle.com
Wed Oct 7 06:39:57 UTC 2020


Hi Erik,

On 6/10/2020 5:37 pm, Erik Österlund wrote:
> On Tue, 6 Oct 2020 02:57:00 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Hi Erik,
>> Can you give an overview of the use of the "poll word" and its relation to the "poll page" please?
>> Thanks,
>> David
> 
> Hi David,
> 
> Thanks for reviewing this code.
> 
> There are various polls in the VM. We have runtime transitions, interpreter transitions, transitions at returns, native
> wrappers, transitions in nmethods... and sometimes they are a bit different.
> 
> The "poll word" encapsulates enough information to be able to poll for returns (stack watermark barrier), or poll for
> normal handshakes/safepoints, with a conditional branch. So really, we could use the "poll word" for every single poll.
> A low order bit is a boolean saying if handshake/safepoint is armed, and the rest of the word denotes the watermark for
> which frame has armed returns.
> 
> The "poll page" is for polls that do not use conditional branches, but instead uses an indirect load. It is used still
> in nmethod loop polls, because I experimentally found it to perform worse with conditional branches on one machine, and
> did not want to risk regressions. It is also used for VM configurations that do not yet support stack watermark
> barriers, such as Graal, PPC, S390 and 32 bit platforms. They will hopefully eventually support this mechanism, but
> having the poll page allows a more smooth transition. And unless it is crystal clear that the performance of the
> conditional branch loop poll really is fast enough on sufficiently many machines, we might keep it until that changes.
> 
> Hope this makes sense.

Yes but I am somewhat surprised. The conventional wisdom has always been 
that polling based on the "poison page" approach far outperforms 
explicit load-test-branch approaches.

Cheers,
David

> Thanks,
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/296
> 


More information about the serviceability-dev mailing list