RFR(XL): 8185640: Thread-local handshakes

[Andrew Haley]

On 26/10/17 15:39, Erik Österlund wrote:

> The reason we do not poll the page in the interpreter is that we
> need to generate appropriate relocation entries in the code blob for
> the PCs that we poll on, so that we in the signal handler can look
> up the code blob, walk the relocation entries, and find precisely
> why we got the trap, i.e. due to the poll, and precisely what kind
> of poll, so we know what trampoline needs to be taken into the
> runtime.

Not really, no.  If we know that we're in the interpreter and the
faulting address is the safepoint poll, then we can read all of the
context we need from the interpreter registers and the frame.

> While constructing something that does that is indeed possible, it
> simply did not seem worth the trouble compared to using a branch in
> these paths. The same reasoning applies for the poll performed in
> the native wrapper when waking up from native and transitioning into
> Java. It performs a conditional branch instead of indirect load to
> avoid signal handler logic for polls that are not performance
> critical.

If we're talking about performance, the existing bytecode interpreter
is exquisitely carefully coded, even going to the extent of having
multiple dispatch tables for safepoint- and non-safepoint cases.
Clearly the original authors weren't thinking that code was not
performance critical or they wouldn't have done what they did.  I
suppose, though, that the design we have is from the early days when
people diligently strove to make the interpreter as fast as possible.

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