RFR(XL): 8185640: Thread-local handshakes
erik.osterlund at oracle.com
Thu Oct 26 14:39:47 UTC 2017
On 2017-10-26 10:58, Andrew Haley wrote:
> BTW, I don't understand why interpreted code doesn't simply read the
> polling page. Or we could even simply read-protect the bytecode
> dispatch tables themselves.
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. 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.
Only the polls in JIT-compiled code use the optimized indirect load
And we do not want to read-protect the bytecode dispatch tables, because
we want the ability to stop individual threads, and that would stop all
I hope that explains it.
More information about the hotspot-dev