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

8264711: More runtime TRAPS cleanups #3345

Closed
wants to merge 4 commits into from
Closed

Conversation

hseigel
Copy link
Member

@hseigel hseigel commented Apr 5, 2021

Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold


Progress

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

Issue

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3345/head:pull/3345
$ git checkout pull/3345

Update a local copy of the PR:
$ git checkout pull/3345
$ git pull https://git.openjdk.java.net/jdk pull/3345/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3345

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3345.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Apr 5, 2021

👋 Welcome back hseigel! 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 Pull request is ready for review label Apr 5, 2021
@openjdk
Copy link

openjdk bot commented Apr 5, 2021

@hseigel The following labels will be automatically applied to this pull request:

  • hotspot
  • serviceability

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

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Apr 5, 2021
@mlbridge
Copy link

mlbridge bot commented Apr 5, 2021

Webrevs

Copy link
Member

@lfoltan lfoltan 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 Harold. One minor comment for the file jfrJavaSupport.cpp.

Thanks,
Lois

src/hotspot/share/jfr/jni/jfrJavaSupport.cpp Outdated Show resolved Hide resolved
@openjdk
Copy link

openjdk bot commented Apr 5, 2021

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

8264711: More runtime TRAPS cleanups

Reviewed-by: lfoltan, pchilanomate, dholmes, dcubed

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

  • ec599da: 8264633: Add missing logging to PlatformRecording#stop
  • e89542f: 8264352: AArch64: Optimize vector "not/andNot" for NEON and SVE
  • 016db40: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to
  • 78d1164: 8214455: Relocate CDS archived regions to the top of the G1 heap
  • 88eb291: 8264809: test-lib fails to build due to some warnings in ASN1Formatter and jfr
  • a863ab6: 8264551: Unexpected warning when jpackage creates an exe
  • 6e2b82a: 8264731: Introduce InstanceKlass::method_at_itable_or_null()
  • 22b20f8: 8264424: Support OopStorage bulk allocation
  • ab3be72: 8264863: Update JCov version to support JDK 17
  • 774e5ae: 8264742: member variable _monitor of MonitorLocker is redundant
  • ... and 29 more: https://git.openjdk.java.net/jdk/compare/104e925dfdac0af3b1c6862f9a7d3442484f9241...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.

➡️ 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 Apr 5, 2021
@@ -2735,7 +2735,7 @@ JNI_ENTRY(jint, jni_MonitorExit(JNIEnv *env, jobject jobj))
}

Handle obj(THREAD, JNIHandles::resolve_non_null(jobj));
ObjectSynchronizer::jni_exit(obj(), CHECK_(JNI_ERR));
ObjectSynchronizer::jni_exit(THREAD->as_Java_thread(), obj());
Copy link
Contributor

Choose a reason for hiding this comment

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

Here we would return JNI_ERR if we throw IMSE from jni_exit().

Copy link
Contributor

@pchilano pchilano left a comment

Choose a reason for hiding this comment

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

Hi Harold,

I looked at the changes to synchronization code and looks good except for one issue below.

Thanks,
Patricio

@hseigel
Copy link
Member Author

hseigel commented Apr 5, 2021

Thanks Lois and Patricio for reviewing the change!
I removed my bogus change to ObjectSynchronizer::jni_exit() which also made calls consistent in jfrJavaSupport.cpp.
Harold

@pchilano
Copy link
Contributor

pchilano commented Apr 5, 2021

Thanks Lois and Patricio for reviewing the change!
I removed my bogus change to ObjectSynchronizer::jni_exit() which also made calls consistent in jfrJavaSupport.cpp.
Harold
Thanks Harold! Fix looks good.

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.

Hi Harold,

Lots of good cleanup here but also a couple of things that I think are incorrect. Platform string creation can throw exceptions; and I also believe the ClassFileLoadHook can too.

Thanks,
David

@@ -393,7 +393,7 @@ Handle java_lang_String::create_from_symbol(Symbol* symbol, TRAPS) {
}

// Converts a C string to a Java String based on current encoding
Handle java_lang_String::create_from_platform_dependent_str(const char* str, TRAPS) {
Handle java_lang_String::create_from_platform_dependent_str(JavaThread* current, const char* str) {
Copy link
Member

Choose a reason for hiding this comment

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

This change is incorrect. JNU_NewStringPlatform can raise an exception so TRAPS here is correct.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for finding this. I reverted this change and the change to as_platform_dependent_str() because it calls GetStringPlatformChars() which calls JNU_GetStringPlatformChars() which can throw an exception.

Symbol* name,
ClassLoaderData* loader_data,
Handle protection_domain,
JvmtiCachedClassFileData** cached_class_file,
TRAPS) {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this removal of TRAPS is correct. The ClassFileLoadHook could result in an exception becoming pending.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks! This change was reverted.

@@ -706,7 +706,7 @@ JvmtiEnv::AddToSystemClassLoaderSearch(const char* segment) {
ObjectLocker ol(loader, THREAD);

// need the path as java.lang.String
Handle path = java_lang_String::create_from_platform_dependent_str(segment, THREAD);
Handle path = java_lang_String::create_from_platform_dependent_str(THREAD, segment);
Copy link
Member

Choose a reason for hiding this comment

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

This change will need reverting as an exception is possible as previously noted.

But note that if there was no possibility of exception here then the following check of HAS_PENDING_EXCEPTION should also have been removed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Reverted.

@mlbridge
Copy link

mlbridge bot commented Apr 5, 2021

Mailing list message from David Holmes on serviceability-dev:

On 6/04/2021 5:14 am, Patricio Chilano Mateo wrote:

src/hotspot/share/prims/jni.cpp line 2738:

2736:
2737: Handle obj(THREAD, JNIHandles::resolve_non_null(jobj));
2738: ObjectSynchronizer::jni_exit(THREAD->as_Java_thread(), obj());

Here we would return JNI_ERR if we throw IMSE from jni_exit().

Strictly speaking we probably should return JNI_ERR in that case, but
the spec (as usual) is non-specific about the relationship between error
codes and throwing exceptions. I would not suggest making such a change
now. Note that we would have to be careful to only return JNI_ERR in the
single case of IMSE, and even then we would have to be certain that the
IMSE came from the actual "exit" and not e.g.

err = MonitorEnter(obj);
...
throwIMSE()
...
err = MonitorExit(obj)

Cheers,
David

@hseigel
Copy link
Member Author

hseigel commented Apr 7, 2021

Please review this latest version of this change containing reviewer suggested changes.

Thanks, Harold

@@ -157,15 +157,6 @@ Method* Bytecode_invoke::static_target(TRAPS) {
return LinkResolver::resolve_method_statically(bc, constants, index(), THREAD);
}

Handle Bytecode_invoke::appendix(TRAPS) {
Copy link
Member

Choose a reason for hiding this comment

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

You might want to mention the removal of this function in
the bug report so that it will show up in a JBS search.

@dcubed-ojdk
Copy link
Member

Thumbs up.

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.

Hi Harold,

Updates seem fine.

Thanks,
David

@hseigel
Copy link
Member Author

hseigel commented Apr 8, 2021

Thanks Lois, Patricio, David, and Dan for reviewing this!

/integrate

@openjdk openjdk bot closed this Apr 8, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Apr 8, 2021
@openjdk
Copy link

openjdk bot commented Apr 8, 2021

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

  • 3aec2d9: 8264718: Shenandoah: enable string deduplication during root scanning
  • 255afbe: 8264672: runtime/ParallelLoad/ParallelSuperTest.java timed out
  • ec599da: 8264633: Add missing logging to PlatformRecording#stop
  • e89542f: 8264352: AArch64: Optimize vector "not/andNot" for NEON and SVE
  • 016db40: 8263907: Specification of CellRendererPane::paintComponent(..Rectangle) should clearly mention which method it delegates the call to
  • 78d1164: 8214455: Relocate CDS archived regions to the top of the G1 heap
  • 88eb291: 8264809: test-lib fails to build due to some warnings in ASN1Formatter and jfr
  • a863ab6: 8264551: Unexpected warning when jpackage creates an exe
  • 6e2b82a: 8264731: Introduce InstanceKlass::method_at_itable_or_null()
  • 22b20f8: 8264424: Support OopStorage bulk allocation
  • ... and 31 more: https://git.openjdk.java.net/jdk/compare/104e925dfdac0af3b1c6862f9a7d3442484f9241...master

Your commit was automatically rebased without conflicts.

Pushed as commit af13c64.

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