RFR: 8265754: Move suspend/resume API from HandshakeState [v2]

[Anton Artemov]

On Mon, 2 Jun 2025 15:56:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that’s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3
>
>> @pchilano Do you expect to have any performance impact of having an indirection layer?
>> 
> No concern about performance, just where the code should be for better design and simplicity.
> 
>> Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`.
>> 
> The reason is the interaction with the `HandshakeState` lock. Before, each `JavaThread` had a suspend/resume monitor (`_SR_lock`), but now we are directly using the one from the `HandshakeState` since that’s what the `JavaThread` is holding already when suspending.  
> 
>> An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach?
>> 
> The issue is that you would have to keep those methods that need access to it in `HandshakeState`.
> 
>> Another option is to keep things in `HandhshakeSuspender` and give it access to the `HandshakeState `lock , but move `_suspended`/`_async_suspend_handshake` in the suspender. Then, methods should no longer be static, and the suspender itself would be owned by JavaThread, similarly to `HandshakeState `instance.
>>
> That sounds better. I would personally leave it in `JavaThread` but encapsulating the implementation like that in a new class looks good too.

@pchilano I refactored the code, please take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2934752961