8259713: Fix comments about ResetNoHandleMark in deoptimization #2069

coleenp · 2021-01-13T21:12:34Z

This is a small part of the withdrawn change for #1990 to fix the out-of-date comments in deoptimization.cpp.
Tested with tier1-3.

Progress

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

Issue

JDK-8259713: Fix comments about ResetNoHandleMark in deoptimization

Reviewers

Lois Foltan (@lfoltan - Reviewer) ⚠️ Review applies to 024660f
Daniel D. Daugherty (@dcubed-ojdk - Reviewer)
David Holmes (@dholmes-ora - Reviewer)

Download

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

bridgekeeper · 2021-01-13T21:13:25Z

👋 Welcome back coleenp! 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 · 2021-01-13T21:14:21Z

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

mlbridge · 2021-01-13T21:17:14Z

Webrevs

01: Full - Incremental (6b76e6f)
00: Full (024660f)

lfoltan

LGTM.
Lois

openjdk · 2021-01-13T21:37:05Z

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

8259713: Fix comments about ResetNoHandleMark in deoptimization

Reviewed-by: lfoltan, dcubed, dholmes

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

d18d26e: 8259350: Add some internal debugging APIs to the debug agent
a6b2162: 8259278: Optimize Vector API slice and unslice operations
da6bcf9: 8255019: Shenandoah: Split STW and concurrent mark into separate classes
aba3431: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result
8554fe6: 8253866: Security Libs Terminology Refresh
c2a3c7e: 8259727: Remove redundant "target" arguments to methods in Links
1620664: 8259723: Move Table class to formats.html package
38a1201: 8258912: Remove JVM options CountJNICalls and CountJVMCalls
be57cf1: 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests
c822eda: 8259699: Reduce char[] copying in URLEncoder.encode(String, Charset)
... and 32 more: https://git.openjdk.java.net/jdk/compare/535f2da5e2f58e92b5b788faac25c53acb3750b8...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.

coleenp · 2021-01-13T21:39:57Z

Thanks Lois!

dcubed-ojdk · 2021-01-13T21:43:03Z

src/hotspot/share/runtime/deoptimization.cpp

-  ResetNoHandleMark rnhm; // No-op in release/product versions
+  // Beware though because allocating Handles must have a HandleMark or else the
+  // Handles will be leaked.
+  ResetNoHandleMark rnhm;


So I'm confused. The bug description says:

the ResetNoHandleMark is unneeded

but it is still here.

This one is needed because it's in a JRT_LEAF. The one above in the JRT_BLOCK_ENTRY is unneeded (along with the comment that matched the one in this unpack_frames() function.)

Correction, I didn't remove a ResetNoHandleMark in fetch_unroll_info, because there wasn't one there. It was removed already. I just removed the comment that described the code that isn't there anymore.

dcubed-ojdk · 2021-01-13T21:43:40Z

src/hotspot/share/runtime/deoptimization.cpp

+  // Beware though because allocating Handles must have a HandleMark or else the
+  // Handles will be leaked.


This comment is confusing because there is HandleMark on L693.

My point of this comment is that you should make sure you have a HandleMark if you've used ResetNoHandleMark in JRT_LEAF.

dcubed-ojdk · 2021-01-13T22:42:07Z

The comment in the bug says this:

The comments are wrong and the ResetNoHandleMark is unneeded
since Deoptimization::fetch_unroll_info is a JRT_BLOCK_ENTRY (has a HandleMarkCleaner).

so I read this as you are changing Deoptimization::fetch_unroll_info to:

fix a comment
remove a ResetNoHandleMark

The comment in the bug doesn't mention JRT_LEAF at all, but you're
making comment changes there also.

No where in this fix do I see a ResetNoHandleMark being removed.

Is the reason for my confusion more clear yet?

dcubed-ojdk · 2021-01-14T01:30:21Z

src/hotspot/share/runtime/deoptimization.cpp

-  ResetNoHandleMark rnhm; // No-op in release/product versions
+  // Beware though because allocating Handles must have a HandleMark or else the
+  // Handles will be leaked.
+  ResetNoHandleMark rnhm;
  HandleMark hm(thread);


Here's a simpler rewrite for L687 -> L693:

// This code wants to allocate handles which is okay in a leaf method, // but JRT_LEAF contains a NoHandleMark so we have to work around // that with ResetNoHandleMark in order to create a HandleMark here: ResetNoHandleMark rnhm; HandleMark hm(thread);

Unfortunately this is not entirely what I want to say.
I want to say that you must have a HandleMark if you have ResetNoHandleMark in a JRT_LEAF.
You need a ResetNoHandleMark to create Handles but there are no asserts to make sure you have a HandleMark.
ie:

ResetNoHandleMark rnhm; Handle h(THREAD, obj); // OK no problem

But the Handle will leak once this function returns (until the next JRT_ENTRY anyway).

// This code wants to allocate handles which is okay in a leaf method, // but JRT_LEAF contains a NoHandleMark so we have to work around // that with ResetNoHandleMark in order to create a Handles here. // There must also be a HandleMark here to clean up any handles created in this scope.

How about that?

My suggestion:

// JRT_LEAF methods don't normally allocate handles and there is a // NoHandleMark to enforce that. It is actually safe to use Handles // in a JRT_LEAF method, and sometimes desirable, but to do so we // must use ResetNoHandleMark to bypass the NoHandleMark, and // then use a HandleMark to ensure any Handles we do create are // cleaned up in this scope.

I still question why such a function declares itself a LEAF instead of just being a JRT_ENTRY but that is a different argument. :)
Cheers,
David

Ok, your comment says the same thing as mine and includes what I want to say, so I'll use your comment.
I'm pretty sure this function wants a NoSafepointVerifier but some of the calls it uses might need handles, because we were pretty aggressive about making arguments into handles.

I actually think the HandleMark is there because of the PreserveExceptionMark call in VerifyStack, which is the thing that Erik ran into also with stack watermarks, and prompted the original request about lifting the restrictions for JRT_LEAF functions. I don't want there to be an unhandleized version of PreserveExceptionMark, and I don't want JRT_LEAF to allow Handles by default, so hopefully this comment is adequate documentation.

dcubed-ojdk · 2021-01-14T01:31:26Z

Please fix the bug synopsis and make the PR description match.
Please correct the bug description to describe what you are doing.
I also added a proposed comment rewrite for you.

dcubed-ojdk

I like David's comment much more than the one I proposed!
Thumbs up! For the first time in a long time, I had to use a
webrev to review the code since there were so many comments
in the Git view that made it hard to see the code... :-)

coleenp · 2021-01-14T15:08:08Z

Thanks Dan!

dholmes-ora

LG.

Thanks Coleen!

David

coleenp · 2021-01-14T23:24:19Z

Thanks, David for the suggestions.
/integrate

openjdk · 2021-01-14T23:25:39Z

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

4f881ba: 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping
d18d26e: 8259350: Add some internal debugging APIs to the debug agent
a6b2162: 8259278: Optimize Vector API slice and unslice operations
da6bcf9: 8255019: Shenandoah: Split STW and concurrent mark into separate classes
aba3431: 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result
8554fe6: 8253866: Security Libs Terminology Refresh
c2a3c7e: 8259727: Remove redundant "target" arguments to methods in Links
1620664: 8259723: Move Table class to formats.html package
38a1201: 8258912: Remove JVM options CountJNICalls and CountJVMCalls
be57cf1: 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests
... and 33 more: https://git.openjdk.java.net/jdk/compare/535f2da5e2f58e92b5b788faac25c53acb3750b8...master

Your commit was automatically rebased without conflicts.

Pushed as commit bf28f92.

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

8259713: Fix comments and ResetNoHandleMark in deoptimization

024660f

openjdk bot added the rfr Pull request is ready for review label Jan 13, 2021

openjdk bot added the hotspot hotspot-dev@openjdk.org label Jan 13, 2021

lfoltan approved these changes Jan 13, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 13, 2021

dcubed-ojdk suggested changes Jan 13, 2021

View reviewed changes

dcubed-ojdk reviewed Jan 14, 2021

View reviewed changes

coleenp changed the title ~~8259713: Fix comments and ResetNoHandleMark in deoptimization~~ 8259713: Fix comments about ResetNoHandleMark in deoptimization Jan 14, 2021

Use David's comment.

6b76e6f

dcubed-ojdk approved these changes Jan 14, 2021

View reviewed changes

dholmes-ora approved these changes Jan 14, 2021

View reviewed changes

openjdk bot closed this Jan 14, 2021

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 Jan 14, 2021

coleenp deleted the deopt-comments branch January 15, 2021 00:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8259713: Fix comments about ResetNoHandleMark in deoptimization #2069

8259713: Fix comments about ResetNoHandleMark in deoptimization #2069

coleenp commented Jan 13, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented Jan 13, 2021

openjdk bot commented Jan 13, 2021

mlbridge bot commented Jan 13, 2021 •

edited

Loading

lfoltan left a comment

openjdk bot commented Jan 13, 2021 •

edited

Loading

coleenp commented Jan 13, 2021

dcubed-ojdk Jan 13, 2021

coleenp Jan 13, 2021

coleenp Jan 13, 2021

dcubed-ojdk Jan 13, 2021

coleenp Jan 13, 2021

dcubed-ojdk commented Jan 13, 2021

dcubed-ojdk Jan 14, 2021

coleenp Jan 14, 2021 •

edited

Loading

dholmes-ora Jan 14, 2021

coleenp Jan 14, 2021

coleenp Jan 14, 2021

dcubed-ojdk commented Jan 14, 2021

dcubed-ojdk left a comment

coleenp commented Jan 14, 2021

dholmes-ora left a comment

coleenp commented Jan 14, 2021

openjdk bot commented Jan 14, 2021

		// Beware though because allocating Handles must have a HandleMark or else the
		// Handles will be leaked.

8259713: Fix comments about ResetNoHandleMark in deoptimization #2069

8259713: Fix comments about ResetNoHandleMark in deoptimization #2069

Conversation

coleenp commented Jan 13, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Jan 13, 2021

openjdk bot commented Jan 13, 2021

mlbridge bot commented Jan 13, 2021 • edited Loading

Webrevs

lfoltan left a comment

Choose a reason for hiding this comment

openjdk bot commented Jan 13, 2021 • edited Loading

coleenp commented Jan 13, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dcubed-ojdk commented Jan 13, 2021

Choose a reason for hiding this comment

coleenp Jan 14, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dcubed-ojdk commented Jan 14, 2021

dcubed-ojdk left a comment

Choose a reason for hiding this comment

coleenp commented Jan 14, 2021

dholmes-ora left a comment

Choose a reason for hiding this comment

coleenp commented Jan 14, 2021

openjdk bot commented Jan 14, 2021

coleenp commented Jan 13, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Jan 13, 2021 •

edited

Loading

openjdk bot commented Jan 13, 2021 •

edited

Loading

coleenp Jan 14, 2021 •

edited

Loading