Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8223056: Remove Type-Stable-Memory support for Parkers #2089

Closed
wants to merge 5 commits into from

Conversation

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Jan 15, 2021

As per the bug report, once we ensure the calls to unpark() are guaranteed to only occur on a live thread (protected by a ThreadsListHandle) Parkers (the synchronization object underlying java.util.concurrent.LockSupport) no longer need to use type-stable-memory (TSM).

As a Parker is inherently associated with a single JavaThread, the Parker is now embedded directly in JavaThread, avoiding the need to use new/delete.

The Parker and PlatformParker classes are now simplified from a memory management perspective. I also made them NONCOPYABLE for good measure. Possibly other constraints could be applied to them such as disallowing new/delete? (Though if we go that far maybe we need a new allocation base type?).

Testing: tiers 1-3 plus additional test builds

Thanks,
David


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8223056: Remove Type-Stable-Memory support for Parkers

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2089/head:pull/2089
$ git checkout pull/2089

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jan 15, 2021

👋 Welcome back dholmes! 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 openjdk bot added the rfr label Jan 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 15, 2021

@dholmes-ora The following label will be automatically applied to this pull request:

  • hotspot

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.

@openjdk openjdk bot added the hotspot label Jan 15, 2021
@dholmes-ora
Copy link
Member Author

@dholmes-ora dholmes-ora commented Jan 15, 2021

/label remove hotspot

@dholmes-ora
Copy link
Member Author

@dholmes-ora dholmes-ora commented Jan 15, 2021

/label add hotspot-runtime

@openjdk openjdk bot removed the hotspot label Jan 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 15, 2021

@dholmes-ora
The hotspot label was successfully removed.

@openjdk
Copy link

@openjdk openjdk bot commented Jan 15, 2021

@dholmes-ora
The hotspot-runtime label was successfully added.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 15, 2021

src/hotspot/share/runtime/park.hpp Outdated Show resolved Hide resolved
src/hotspot/share/runtime/park.cpp Show resolved Hide resolved
src/hotspot/os/windows/os_windows.hpp Show resolved Hide resolved
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 20, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Coleen,

Thanks for looking at this.

On 20/01/2021 5:01 am, Coleen Phillimore wrote:

Changes requested by coleenp (Reviewer).

src/hotspot/share/runtime/park.hpp line 58:

56:
57: public:
58: Parker() : PlatformParker(), _counter(0) {

nit generally when empty } is on the same line as {.

Fixed.

I can't find what _counter is used for.

It is the permit counter for the Parker - see the implementations of
park() and unpark() in os_posix.cpp. But if the _counter is Posix only
we should move it into PlatformParker - done.

src/hotspot/share/runtime/park.cpp line 112:

110:
111: void ParkEvent::operator delete (void * a) {
112: // ParkEvents are type-stable and immortal ...

Do ParkEvents still need to be type-stable and immortal as a future RFE?

Yes - see ObjectMonitor::ExitEpilog. We'd have to do a lot of work to be
able to get rid of TSM for ParkEvents.

src/hotspot/os/windows/os_windows.hpp line 205:

203: CloseHandle(_ParkEvent);
204: }
205: };

Should the implementation of the constructor and destructor be in the .cpp file so that thread.hpp doesn't need to include whatever windows os specific file needed to import CreateEvent and CloseHandle?

Sorry I don't follow the connection between os_windows.hpp and
thread.hpp. But note that PlatformEvent in os_windows.hpp already uses
CreateEvent so I have not changed any dependencies in that regard.

BTW it struck me as a poor choice of naming to have a PlatformParker
variable be called _ParkEvent when we have a ParkEvent class, so I've
renamed it to _ParkerEvent.

Thanks,
David

Move _counter field to Posix PlatformParker class.
Rename _ParkEvent to _ParkerEvent on Windows
@robehn
robehn approved these changes Jan 20, 2021
Copy link
Contributor

@robehn robehn left a comment

Thank you!

@openjdk
Copy link

@openjdk openjdk bot commented Jan 20, 2021

@dholmes-ora 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:

8223056: Remove Type-Stable-Memory support for Parkers

Reviewed-by: coleenp, rehn

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 no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready label Jan 20, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 20, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 20/01/2021 5:18 pm, Robbin Ehn wrote:

On Wed, 20 Jan 2021 06:18:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

As per the bug report, once we ensure the calls to unpark() are guaranteed to only occur on a live thread (protected by a ThreadsListHandle) Parkers (the synchronization object underlying java.util.concurrent.LockSupport) no longer need to use type-stable-memory (TSM).

As a Parker is inherently associated with a single JavaThread, the Parker is now embedded directly in JavaThread, avoiding the need to use new/delete.

The Parker and PlatformParker classes are now simplified from a memory management perspective. I also made them NONCOPYABLE for good measure. Possibly other constraints could be applied to them such as disallowing new/delete? (Though if we go that far maybe we need a new allocation base type?).

Testing: tiers 1-3 plus additional test builds

Thanks,
David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

Address Coleen's nit.
Move _counter field to Posix PlatformParker class.
Rename _ParkEvent to _ParkerEvent on Windows

Thank you!

Thanks for the review.

David

Copy link

@coleenp coleenp left a comment

Nice cleanup! Thanks!

src/hotspot/os/windows/os_windows.hpp Outdated Show resolved Hide resolved
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 21, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

On 20/01/2021 11:26 pm, Coleen Phillimore wrote:

On Wed, 20 Jan 2021 06:18:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

As per the bug report, once we ensure the calls to unpark() are guaranteed to only occur on a live thread (protected by a ThreadsListHandle) Parkers (the synchronization object underlying java.util.concurrent.LockSupport) no longer need to use type-stable-memory (TSM).

As a Parker is inherently associated with a single JavaThread, the Parker is now embedded directly in JavaThread, avoiding the need to use new/delete.

The Parker and PlatformParker classes are now simplified from a memory management perspective. I also made them NONCOPYABLE for good measure. Possibly other constraints could be applied to them such as disallowing new/delete? (Though if we go that far maybe we need a new allocation base type?).

Testing: tiers 1-3 plus additional test builds

Thanks,
David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

Address Coleen's nit.
Move _counter field to Posix PlatformParker class.
Rename _ParkEvent to _ParkerEvent on Windows

Nice cleanup! Thanks!

src/hotspot/os/windows/os_windows.hpp line 195:

193:
194: protected:
195: HANDLE _ParkerEvent;

How about calling it _ParkHandle like PlatformEvent above it? Two letters for me is not quickly distinguishable. If you make this change I don't need to see another version.

Done.

Thanks,
David

@dholmes-ora
Copy link
Member Author

@dholmes-ora dholmes-ora commented Jan 21, 2021

/integrate

@openjdk openjdk bot closed this Jan 21, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jan 21, 2021
@dholmes-ora dholmes-ora deleted the dholmes-ora:8223056 branch Jan 21, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 21, 2021

@dholmes-ora Pushed as commit 77a4302.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants