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

8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes #1730

Closed
wants to merge 3 commits into from

Conversation

@dougxc
Copy link
Member

@dougxc dougxc commented Dec 10, 2020

This PR fixes a regression caused by JDK-8257917 by not locking JVMCI_lock when initializing the boxing cache classes.

It also reduces the calls to JVMCI::ensure_box_caches_initialized to be at most one per JVMCI code installation.


Progress

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

Issue

  • JDK-8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes

Reviewers

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 10, 2020

👋 Welcome back dnsimon! 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 openjdk bot commented Dec 10, 2020

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

  • hotspot-compiler

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.

@dougxc dougxc marked this pull request as ready for review Dec 10, 2020
@openjdk openjdk bot added the rfr label Dec 10, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 10, 2020

Webrevs

@dougxc
Copy link
Member Author

@dougxc dougxc commented Dec 10, 2020

Tested with:

sh configure --disable-precompiled-headers --enable-jvm-feature-graal --enable-jvm-feature-aot --enable-debug
jtreg -noreport -jdk:build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/compiler/aot

}
MutexLocker locker(JVMCI_lock);
void JVMCI::ensure_box_caches_initialized(Mutex* lock, TRAPS) {
MutexLocker locker(lock);
// Check again after locking
Copy link
Member

@DamonFool DamonFool Dec 10, 2020

Shall we remove 'again' in the comment?

@@ -945,6 +945,10 @@ JVMCI::CodeInstallResult CodeInstaller::initialize_buffer(CodeBuffer& buffer, bo
}
}
#endif
if (_has_auto_box) {
JavaThread* THREAD = JavaThread::current();
JVMCI::ensure_box_caches_initialized(JVMCI_lock, CHECK_(JVMCI::ok));
Copy link
Member

@DamonFool DamonFool Dec 10, 2020

Why we can hold JVMCI_lock here.
Does it mean that we'll never initialize the box classes at this point?

Copy link
Member Author

@dougxc dougxc Dec 10, 2020

I'm not sure I understand your question - why would we not be able to hold JVMCI_lock here?
That said, based on @veresov 's earlier comment, I'm now inclined to remove the lock altogether. As he says, at worst we harmlessly execute the loop in ensure_box_caches_initialized a few extra times. I've pushed this change.

Copy link
Member

@DamonFool DamonFool Dec 10, 2020

I think we should not hold JVMCI_lock here, because:

  If JVMCI_lock was acquired, then no_safepoint_verifier(new_owner, true) was called [1].
     --> Then, thread->_no_safepoint_count was increased [2].
         --> Then, the assert [3] would fail due to _no_safepoint_count > 0.

What do you think?
Thanks.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/mutex.cpp#L480
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/mutex.cpp#L446
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/thread.cpp#L795

Copy link
Member Author

@dougxc dougxc Dec 10, 2020

Yes, you're right - a VM lock should not be held when leaving the VM to call Java code.
As stated above, I've removed the lock altogether now (91571c1).

@dougxc dougxc changed the title 8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes for AOT 8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes Dec 10, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Dec 10, 2020

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

8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes

Reviewed-by: iveresov

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 4 new commits pushed to the master branch:

  • 0890620: 8258005: JDK build fails with incorrect fixpath script
  • 502a524: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)
  • 026b09c: 8257483: C2: Split immediate vector rotate from RotateLeftV and RotateRightV nodes
  • 0a0691e: 8257901: ZGC: Take virtual memory usage into account when sizing heap

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 label Dec 10, 2020
@dougxc
Copy link
Member Author

@dougxc dougxc commented Dec 10, 2020

/integrate

@openjdk openjdk bot closed this Dec 10, 2020
@openjdk openjdk bot added integrated and removed ready rfr labels Dec 10, 2020
@openjdk
Copy link

@openjdk openjdk bot commented Dec 10, 2020

@dougxc Since your change was applied there have been 6 commits pushed to the master branch:

  • b35401d: 8257966: Instrument test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
  • 37043b0: 8257837: Performance regression in heap byte buffer views
  • 0890620: 8258005: JDK build fails with incorrect fixpath script
  • 502a524: 8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)
  • 026b09c: 8257483: C2: Split immediate vector rotate from RotateLeftV and RotateRightV nodes
  • 0a0691e: 8257901: ZGC: Take virtual memory usage into account when sizing heap

Your commit was automatically rebased without conflicts.

Pushed as commit d163c6f.

💡 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