RFR: 8283044: Use asynchronous handshakes to deliver asynchronous exceptions [v4]

Patricio Chilano Mateo pchilanomate at openjdk.java.net
Tue Mar 29 19:13:51 UTC 2022


On Tue, 29 Mar 2022 01:06:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments
>
> src/hotspot/share/runtime/handshake.cpp line 757:
> 
>> 755: }
>> 756: 
>> 757: void HandshakeState::handle_unsafe_access_error() {
> 
> It bothers me that HandshakeState has to know about unsafe-access-errors. It is not clear to me why this needs to be the case. Ideally all the logic for dealing with UAE would be in the UAE handshake object.

Currently it's only to avoid knowing about the handshake lock outside the HandshakeState class. In a previous version I was also removing the unsafe access operation from the queue inside handle_unsafe_access_error() and that was actually the main reason I moved this method here. Otherwise I was exposing too much about the handshake queue to the outside. 
But now that that is not an issue anymore I think it's probably better to move this to the thread file. Making the less amount of changes to the handshake code was also my intent when I started working on this, since I think handshake.cpp/hpp ideally should only have general handshake mechanism code and be oblivious of individual handshakes. 
There is still a compromise here but it looks like exposing the handshake lock to the JavaThread class seems better than HandshakeState knowing about the handling of this unsafe access error. Also JavaThread is already a friend of HandshakeState so we already have access to the lock even without adding anything. So I can move it back to the thread file if you agree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7930


More information about the hotspot-runtime-dev mailing list