RFR(XL): 8185640: Thread-local handshakes

Erik Österlund erik.osterlund at oracle.com
Thu Oct 26 14:39:47 UTC 2017

Hi Andrew,

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 
of them.

I hope that explains it.


More information about the hotspot-dev mailing list