On Tue, 6 Oct 2020 07:35:16 GMT, Erik Österlund <eosterl...@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 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. Thanks, > _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on > [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_ > > On 06/10/2020 08:22, Erik ?sterlund wrote: > > > > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack > > > Processing" (cf. > > > https://openjdk.java.net/jeps/376). > > One small thing: the couple of uses of lea(InternalAddress) should really be > adr; > this generates much better code. Hi Andrew, Thanks for having a look. I applied your patch. Having said that, this is run on the safepoint slow path, so should be a rather cold path, where threads have to wear coats and gloves. But it does not hurt to optimize the encoding further, I suppose. Thanks, ------------- PR: https://git.openjdk.java.net/jdk/pull/296
