8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 #20012

pchilano · 2024-07-03T16:24:20Z

The ResourceMark added in 8329665 to address the case of having to allocate extra memory for the _bit_mask, prevents code in the closure from allocating and retaining memory from the resource area across the closure, relying on some ResourceMark in scope further up the stack from frame::oops_interpreted_do(). There is in fact one case today in JFR code where this kind of allocation happens.

The amount of locals and expression stack entries a method can have before having to allocate extra memory for the _bit_mask is 4*64/2 = 128. This is already big enough that we almost never have to allocate. A test run through mach5 tiers1-6 shows only a handful of methods that fall into this case, and most are artificial ones created to trigger this condition. So moving the allocation to the C heap shouldn't have any performance penalty as the comment otherwise says. This comment dates back from 2002 where instead of 128 entries we could have only 32, considering 32 bits cpus as still in main use (see bug for more history details).

The current code in InterpreterOopMap::resource_copy() has a comment expecting the InterpreterOopMap object to be recently created and empty, but it also has an assert in the allocation case path where it considers the entry might be in use already. This assert actually looks wrong since a used InterpreterOopMap object will not necessarily contain a pointer to resource area memory in _bit_mask[0]. I added an example case in the bug details. In any case, since we don't have any such cases in the codebase I added an explicit assert to verify each InterpreterOopMap is only used one.

I tested the patch by running it through mach5 tiers 1-6.

Thanks,
Patricio

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-8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 (Bug - P2)

Reviewers

David Holmes (@dholmes-ora - Reviewer) 🔄 Re-review required (review applies to ca0db02b)
Coleen Phillimore (@coleenp - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20012

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

Using diff file

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

Webrev

Link to Webrev Comment

bridgekeeper · 2024-07-03T16:25:05Z

👋 Welcome back pchilanomate! 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 · 2024-07-03T16:26:36Z

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

8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665

Reviewed-by: coleenp, 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 45 new commits pushed to the master branch:

ff49f67: 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file
194425d: 8335645: j.u.Formatter#trailingZeros improved with String repeat
c8acea8: 8335706: G1: Remove unused G1ConcurrentRefine::RemSetSamplingClosure::_cset
bdf470b: 8335742: Problemlist gc/g1/TestMixedGCLiveThreshold.java#25percent with virtual threads
6409ec3: 8335711: G1: Remove unused bot_updates argument in G1AllocRegion constructor
4ec1ae1: 8331385: G1: Prefix HeapRegion helper classes with G1
b9d8056: 8332124: Jcmd should recognise options that look like requests for help
cff9e24: 8335493: check_gc_overhead_limit should reset SoftRefPolicy::_should_clear_all_soft_refs
f4fa35e: 8330954: since-checker - Fix remaining @ since tags in java.base
3050ba0: 8335654: Remove stale hyperlink in divnode.cpp
... and 35 more: https://git.openjdk.org/jdk/compare/fac74b118f5fda4ec297e46238d34ce5b9be1e21...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 · 2024-07-03T16:27:09Z

@pchilano 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 · 2024-07-03T16:43:26Z

Webrevs

dholmes-ora

Thanks for the detailed explanations. A couple of minor (pre-existing) nits but changes are good.

Thanks

dholmes-ora · 2024-07-04T04:47:31Z

src/hotspot/share/interpreter/oopMapCache.cpp

-    "Should not resource allocate the _bit_mask");
-  assert(from->has_valid_mask(),
-    "Cannot copy entry with an invalid mask");
+  // The expectation is that this InterpreterOopMap is a recently created


s/is a recently/is recently/

dholmes-ora · 2024-07-04T04:49:53Z

src/hotspot/share/interpreter/oopMapCache.cpp

 #ifdef ASSERT
-  _resource_allocate_bit_mask = true;
+  _used = false;
 #endif


Nit pre-existing: use of DEBUG_ONLY would be more consistent with later setting of _used.

dholmes-ora · 2024-07-04T04:52:49Z

src/hotspot/share/interpreter/oopMapCache.hpp

@@ -128,11 +129,12 @@ class InterpreterOopMap: ResourceObj {

 public:
  InterpreterOopMap();
+  ~InterpreterOopMap();

  // Copy the OopMapCacheEntry in parameter "from" into this
  // InterpreterOopMap.  If the _bit_mask[0] in "from" points to
  // allocated space (i.e., the bit mask was to large to hold


Nit pre-existing: s/to/too/

dholmes-ora · 2024-07-04T04:53:59Z

src/hotspot/share/interpreter/oopMapCache.hpp

-  // in-line), allocate the space from a Resource area.
+  // in-line), allocate the space from the C heap.
  void resource_copy(OopMapCacheEntry* from);


The name resource_copy seems somewhat of a misnomer given it may be C heap. Is it worth changing?

I agree, this should probably be copy_from, and rename the parameter src. Or something like that.

I also thought about renaming it but ended up leaving it as is in v1. I changed it to Coleen's suggestion.

coleenp

Also a couple of nits, but this looks good. Thanks for tracking down the history and verifying that its an unusual situation that we were optimizing for.

coleenp · 2024-07-05T12:32:53Z

src/hotspot/share/interpreter/oopMapCache.hpp

-// a resource area for better performance.  InterpreterOopMap
+// For InterpreterOopMap the bit_mask is allocated in the C heap
+// to avoid issues with allocations from the resource area that have
+// to live accross the oop closure (see 8335409). InterpreterOopMap


We don't usually put bug numbers in the code and after this change nobody will want to move this back to resource area, so putting the bug number as a caution shouldn't be needed. If one wants to know the details, they can git blame this file.

coleenp · 2024-07-05T12:33:42Z

src/hotspot/share/interpreter/oopMapCache.hpp

-// a resource area for better performance.  InterpreterOopMap
+// For InterpreterOopMap the bit_mask is allocated in the C heap
+// to avoid issues with allocations from the resource area that have
+// to live accross the oop closure (see 8335409). InterpreterOopMap
 // should only be created and deleted during same garbage collection.


Can you add 'the' to "during the same garbage collection."

coleenp · 2024-07-05T12:34:55Z

src/hotspot/share/interpreter/oopMapCache.hpp

-  // in-line), allocate the space from a Resource area.
+  // in-line), allocate the space from the C heap.
  void resource_copy(OopMapCacheEntry* from);


I agree, this should probably be copy_from, and rename the parameter src. Or something like that.

coleenp · 2024-07-05T14:34:57Z

src/hotspot/share/interpreter/oopMapCache.hpp

@@ -89,7 +90,7 @@ class InterpreterOopMap: ResourceObj {

 protected:
 #ifdef ASSERT
-  bool _resource_allocate_bit_mask;
+  bool           _used;


Can you make this a DEBUG_ONLY() too?

coleenp

One tiny nit.

coleenp

Perfect, thanks!

v1

ca0db02

openjdk bot added the hotspot [email protected] label Jul 3, 2024

pchilano marked this pull request as ready for review July 3, 2024 16:39

openjdk bot added the rfr Pull request is ready for review label Jul 3, 2024

dholmes-ora approved these changes Jul 4, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 4, 2024

coleenp reviewed Jul 5, 2024

View reviewed changes

pchilano added 2 commits July 5, 2024 09:57

David's comments

127ae6e

Coleen's comments

805358e

openjdk bot removed the ready Pull request is ready to be integrated label Jul 5, 2024

coleenp reviewed Jul 5, 2024

View reviewed changes

use DEBUG_ONLY on _used declaration

7ce559c

coleenp approved these changes Jul 5, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 5, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 #20012

8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 #20012

pchilano commented Jul 3, 2024 •

edited by openjdk bot

Loading

bridgekeeper bot commented Jul 3, 2024

openjdk bot commented Jul 3, 2024 •

edited

Loading

openjdk bot commented Jul 3, 2024

mlbridge bot commented Jul 3, 2024 •

edited

Loading

dholmes-ora left a comment

dholmes-ora Jul 4, 2024

pchilano Jul 5, 2024

dholmes-ora Jul 4, 2024

pchilano Jul 5, 2024

dholmes-ora Jul 4, 2024

pchilano Jul 5, 2024

dholmes-ora Jul 4, 2024

coleenp Jul 5, 2024

pchilano Jul 5, 2024

coleenp left a comment

coleenp Jul 5, 2024

pchilano Jul 5, 2024

coleenp Jul 5, 2024

pchilano Jul 5, 2024

coleenp Jul 5, 2024

coleenp Jul 5, 2024

pchilano Jul 5, 2024

coleenp left a comment

coleenp left a comment

8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 #20012

Are you sure you want to change the base?

8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665 #20012

Conversation

pchilano commented Jul 3, 2024 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Jul 3, 2024

openjdk bot commented Jul 3, 2024 • edited Loading

openjdk bot commented Jul 3, 2024

mlbridge bot commented Jul 3, 2024 • edited Loading

Webrevs

dholmes-ora left a 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

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

Choose a reason for hiding this comment

coleenp left a 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

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

coleenp left a comment

Choose a reason for hiding this comment

coleenp left a comment

Choose a reason for hiding this comment

pchilano commented Jul 3, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Jul 3, 2024 •

edited

Loading

mlbridge bot commented Jul 3, 2024 •

edited

Loading