8265754: Move suspend/resume API from HandshakeState

[toxaart]

Hi,

in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class.

Tested in tiers 1-4.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8265754: Move suspend/resume API from HandshakeState (Enhancement - P4)

Reviewers

• David Holmes (@dholmes-ora - Reviewer) Review applies to 1d34f5ad
• Patricio Chilano Mateo (@pchilano - Reviewer) Review applies to 1d34f5ad
• Coleen Phillimore (@coleenp - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407
$ git checkout pull/25407

Update a local copy of the PR:
$ git checkout pull/25407
$ git pull https://git.openjdk.org/jdk.git pull/25407/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25407

View PR using the GUI difftool:
$ git pr show -t 25407

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25407.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back toxaart! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@toxaart This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8265754: Move suspend/resume API from HandshakeState

Reviewed-by: coleenp, dholmes, pchilanomate

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 11 new commits pushed to the master branch:

• bf7d40d: 8356751: IGV: clean up redundant field _should_send_method
• 5ae32c4: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty
• 56ce70c: 8359165: AIX build broken after 8358799
• ... and 8 more: https://git.openjdk.org/jdk/compare/7c9c8ba363521a7bfb58e1a8285459f717769889...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@dholmes-ora, @pchilano, @coleenp) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

@toxaart The following label will be automatically applied to this pull request:

• hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 11: Full - Incremental (00a9faaa)
• 10: Full - Incremental (1d34f5ad)
• 09: Full - Incremental (8d24cd75)
• 08: Full - Incremental (272b0293)
• 07: Full - Incremental (c07b29ea)
• 06: Full - Incremental (4c984b2e)
• 05: Full - Incremental (93b87cfa)
• 04: Full - Incremental (425ec18e)
• 03: Full - Incremental (2f6a26d4)
• 02: Full - Incremental (3b0fffab)
• 01: Full - Incremental (0ee1abf2)
• 00: Full (b852ba9c)

[dholmes-ora]

This refactoring seems okay to me.

Thanks

[pchilano]

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: pchilano@4e87006

[toxaart]

Thanks @pchilano, I agree that the refactoring I proposed is adding an extra layer. What you propose is moving the functionality to JavaThread. I think we need to come to an agreement on where it should belong to. @dholmes-ora do you have an opinion on that?

[dholmes-ora]

@toxaart All the suspend/resume code used to live in JavaThread so we are coming full-circle. :) I don't quite recall the path that led to it being taken out of JavaThread. No objections from me.

[toxaart]

@pchilano Do you expect to have any performance impact of having an indirection layer?

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.

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?

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.

[pchilano]

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

[openjdk]

@toxaart
Reviewer coleenp successfully credited.

[dholmes-ora]

I am okay with this refactoring. I will let you and Patricio iron out any further wrinkles.

Thanks.

[pchilano]

Looks good to me, thanks!

[toxaart]

/integrate

[openjdk]

@toxaart
Your change (at version 1d34f5a) is now ready to be sponsored by a Committer.

[coleenp]

Just needs a copyright fix.

[toxaart]

/integrate

[coleenp]

/sponsor

[openjdk]

@toxaart
Your change (at version 00a9faa) is now ready to be sponsored by a Committer.

[coleenp]

/sponsor

[openjdk]

Going to push as commit 42ab8fcfb98eacb2d93f59c012360a99a16e5450.
Since your change was applied there have been 11 commits pushed to the master branch:

• bf7d40d: 8356751: IGV: clean up redundant field _should_send_method
• 5ae32c4: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty
• 56ce70c: 8359165: AIX build broken after 8358799
• ... and 8 more: https://git.openjdk.org/jdk/compare/7c9c8ba363521a7bfb58e1a8285459f717769889...master

Your commit was automatically rebased without conflicts.

[openjdk]

@coleenp @toxaart Pushed as commit 42ab8fc.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[openjdk]

@coleenp The command sponsor can only be used in open pull requests.