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

[David Holmes]

On Tue, 29 Mar 2022 19:10:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

Future cleanup please. It bothers me that we have to know about the internal locking because we don't want to be holding that lock when calling out to Java, and it bothers me that we are calling out to Java in the first place as that starts to encounter the "Java-in-Java" issues that we know about from other work.

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

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