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

8313224: Avoid calling JavaThread::current() in MemAllocator::Allocation constructor #15058

Conversation

iklam
Copy link
Member

@iklam iklam commented Jul 27, 2023

Summary: Avoid calling JavaThread::current() since we already have a Thread* in MemAllocator::_thread.

Although the latter is declared to be a Thead* and not a JavaThread*, the calling context requires the current thread to be a JavaThread, and MemAllocator::_thread was initialized to be Thread::current, so I changed the code from

_thread(JavaThread::current()),

to

assert(Thread::current()->is_Java_thread(), "must be used by JavaThreads only");
assert(Thread::current() == allocator._thread, "do not pass MemAllocator across threads");
_thread = JavaThread::cast(allocator._thread);

I also clean up a few other lines to limit the explicit use of JavaThread*.

This fix improved java --version by about 0.6% for my prototype of JDK-8310823, which allocates ~24000 heap objects at VM start-up.


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-8313224: Avoid calling JavaThread::current() in MemAllocator::Allocation constructor (Enhancement - P4)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15058

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

Using diff file

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

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jul 27, 2023

👋 Welcome back iklam! 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
Copy link

openjdk bot commented Jul 27, 2023

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

  • hotspot-gc

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-gc hotspot-gc-dev@openjdk.org label Jul 27, 2023
@iklam iklam marked this pull request as ready for review July 27, 2023 20:50
@openjdk openjdk bot added the rfr Pull request is ready for review label Jul 27, 2023
@mlbridge
Copy link

mlbridge bot commented Jul 27, 2023

Webrevs

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks okay but one query below.

Thanks.

@@ -95,7 +97,7 @@ class MemAllocator::Allocation::PreserveObj: StackObj {
oop* const _obj_ptr;

public:
PreserveObj(JavaThread* thread, oop* obj_ptr)
PreserveObj(Thread* thread, oop* obj_ptr)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you change this? Following through the usage call chain it is only used by the _thread from Allocation which has to be a JavaThread.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to minimize the use of JavaThread. Most of the MemAllocator APIs take Thread, so any occurrence of JavaThread looks suspicious and may cause people to unwittingly cast from Thread to JavaThread in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a most confusing set of classes. Why doesn't MemAllocator take a JavaThread? Which _thread does this code use? I think the more specific type is generally better. It doesn't seem like a bad thing for the caller to be required to have a JavaThread. Its caller does have a JavaThread.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes MemAllocator is used by non-Java threads (e.g., GC threads uses it to create filler objects).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted the change in PreserveObj, which is a private inner class of MemAllocator::Allocation, so the use of JavaThread* doesn't leak to the outside world.

Copy link
Contributor

@tschatzl tschatzl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, with some minor comments about superfluous asserts.

_obj_ptr(obj_ptr),
_overhead_limit_exceeded(false),
_allocated_outside_tlab(false),
_allocated_tlab_size(0),
_tlab_end_reset_for_sample(false)
{
assert(Thread::current()->is_Java_thread(), "must be used by JavaThreads only");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This first assert duplicates the one done by JavaThread::cast() given the other assert just below.

_obj_ptr(obj_ptr),
_overhead_limit_exceeded(false),
_allocated_outside_tlab(false),
_allocated_tlab_size(0),
_tlab_end_reset_for_sample(false)
{
assert(Thread::current()->is_Java_thread(), "must be used by JavaThreads only");
assert(Thread::current() == allocator._thread, "do not pass MemAllocator across threads");
_thread = JavaThread::cast(allocator._thread);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The assignment could also be done in the initializer list as it seems simple enough.

@openjdk
Copy link

openjdk bot commented Aug 1, 2023

@iklam 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:

8313224: Avoid calling JavaThread::current() in MemAllocator::Allocation constructor

Reviewed-by: tschatzl, coleenp

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 1 new commit pushed to the master branch:

  • 9abb2a5: 8312461: JNI warnings in SunMSCApi provider

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

➡️ 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 Pull request is ready to be integrated label Aug 1, 2023
Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's good to remove some thread arguments to eliminate some source of confusion.

@@ -95,7 +97,7 @@ class MemAllocator::Allocation::PreserveObj: StackObj {
oop* const _obj_ptr;

public:
PreserveObj(JavaThread* thread, oop* obj_ptr)
PreserveObj(Thread* thread, oop* obj_ptr)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a most confusing set of classes. Why doesn't MemAllocator take a JavaThread? Which _thread does this code use? I think the more specific type is generally better. It doesn't seem like a bad thing for the caller to be required to have a JavaThread. Its caller does have a JavaThread.

Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@iklam
Copy link
Member Author

iklam commented Aug 11, 2023

Thanks for the review @tschatzl @coleenp

/integrate

@openjdk
Copy link

openjdk bot commented Aug 11, 2023

Going to push as commit 43462a3.
Since your change was applied there has been 1 commit pushed to the master branch:

  • 9abb2a5: 8312461: JNI warnings in SunMSCApi provider

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Aug 11, 2023
@openjdk openjdk bot closed this Aug 11, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Aug 11, 2023
@openjdk
Copy link

openjdk bot commented Aug 11, 2023

@iklam Pushed as commit 43462a3.

💡 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
Labels
hotspot-gc hotspot-gc-dev@openjdk.org integrated Pull request has been integrated
4 participants