8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled #28741

stefank · 2025-12-10T10:33:04Z

Found this while poking around at Valhalla that turned off heap sharing. The fix is simple, there's a missing HeapShared::is_loading() check that we missed when refactoring the object streaming code.

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-8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled (Bug - P4)

Reviewers

Aleksey Shipilev (@shipilev - Reviewer)
Ioi Lam (@iklam - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28741

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

Using diff file

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

Using Webrev

Link to Webrev Comment

…eap is disabled

stefank · 2025-12-10T10:33:59Z

This is the assert that you get when hitting this issue:

#  assert(_heap_load_mode != HeapArchiveMode::_uninitialized) failed: not initialized yet

bridgekeeper · 2025-12-10T10:34:23Z

👋 Welcome back stefank! 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 · 2025-12-10T10:35:59Z

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

8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled

Reviewed-by: shade, iklam

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

2a1c676: 8373464: Test JdkManagementCheckSince.java fails after JDK-8369736
b0bd0c3: 8372759: Test build/AbsPathsInImage.java fails after JDK-8370438
e1d1d53: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics with erroneous bounds for characters with no outline (e.g., the space character ' ')
... and 28 more: https://git.openjdk.org/jdk/compare/830c4d3b198597b6af7a21b708bd3a852af200d4...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 · 2025-12-10T10:36:38Z

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

hotspot-runtime

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 · 2025-12-10T10:39:38Z

Webrevs

01: Full - Incremental (a1dde921)
00: Full (4221e141)

iklam · 2025-12-10T17:27:17Z

test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java

+ * @modules java.base/jdk.internal.misc
+ *          java.management


Is this required?

I don't know. I copy-n-pasted the code from PrintSharedArchiveAndExit.java and didn't think about it.

iklam · 2025-12-10T17:28:06Z

test/hotspot/jtreg/runtime/cds/PrintSharedArchiveAndExitNoHeap.java

- *
- * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:SpecTrapLimitExtraEntries=0 compiler.arguments.TestSpecTrapLimitExtraEntries
- * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:SpecTrapLimitExtraEntries=100 compiler.arguments.TestSpecTrapLimitExtraEntries
+ * @summary Testing -XX:+PrintSharedArchiveAndExit option with no shared heap


Please add bug ID.

Just curious: why is that important? I would have guessed that the git history would be sufficient to figure this out.

jtreg allows running the tests related to a particular bug ID: https://openjdk.org/jtreg/command-help.html -- although I don't know who uses this feature instead of just running the majority of the tests most of the time :)

-bug:<bugid> Run only those tests which apply to the given bugid.

OK. I've never felt the need or want to use that :D. I'll add the bugid.

The reason I asked for the bug ID:

The usage in this test is not common: java -XX:AOTCacheOutput=... -XX:+PrintSharedArchiveAndExit will not create the specified AOT cache. Having the bug ID will make it easy to understand why the test is written in this way.

OK. I would have used git for that ...

shipilev

Hold on, how does it crash? I cannot see right away how this would fail:

size_t StringTable::shared_entry_count() {
  assert(HeapShared::is_loading_mapping_mode(), "should not reach here");
  return _shared_table.entry_count();
}

class SimpleCompactHashtable {
  ...
  inline size_t entry_count() const {
    return _entry_count;
  }
  ...
}

static SharedStringTable _shared_table;

The assert in StringTable::shared_entry_count() is likely incomplete too.

shipilev · 2025-12-11T07:22:48Z

Hold on, how does it crash?

Oh, so it fails the assert in the mode checker:

inline bool HeapShared::is_loading_mapping_mode() {
  assert(_heap_load_mode != HeapArchiveMode::_uninitialized, "not initialized yet"); // <---
  return _heap_load_mode == HeapArchiveMode::_mapping;
}

All right. The assert in StringTable::shared_entry_count() needs fixing as well then.

stefank · 2025-12-11T08:52:26Z

Hold on, how does it crash? I cannot see right away how this would fail:
size_t StringTable::shared_entry_count() {
  assert(HeapShared::is_loading_mapping_mode(), "should not reach here");
  return _shared_table.entry_count();
}

class SimpleCompactHashtable {
  ...
  inline size_t entry_count() const {
    return _entry_count;
  }
  ...
}

static SharedStringTable _shared_table;
The assert in StringTable::shared_entry_count() is likely incomplete too.

That one has been left as-is intentionally. We should never call shared_entry_count without having enabled "heap sharing" and "loading mode of heap sharing". If anyone would try to call it without enabling/initializing "loading mode", then we'll get an appropriate assert that the loading mode has not been initialized.

stefank · 2025-12-11T08:56:54Z

I could change the code to:

size_t StringTable::shared_entry_count() {
  assert(HeapShared::is_loading(), "should not reach here");
  assert(HeapShared::is_loading_mapping_mode(), "should not reach here");
  return _shared_table.entry_count();
}

Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it.

shipilev · 2025-12-11T09:38:56Z

Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it.

Meh, can go either way. I won't quibble for this patch.

Honestly, my expectation is that when HeapShared::is_loading_mapping_mode() == true, then HeapShared::is_loading() == true, and when is_loading_mapping_mode() == false, then is_loading() is undefined/dont-care value. In that sense, current code that checks only HeapShared::is_loading_mapping_mode() would have been correct already. But I am guessing you don't want to miss a bug when is_loading_mapping_mode() returns false, just because we have a lifecycle bug somewhere and loading mode is uninitialized. OTOH, it is literally the same as checking is_loading() explicitly like your PR does, so it gains us nothing safety-wise, and only confuses ourselves. Maybe rethinking the state machinery a bit here would be a good cleanup.

stefank · 2025-12-11T09:50:28Z

Personally, I think it is redundant, because the second assert would catch a failure of the first. But if you all think this is better, then I'll add it.

Meh, can go either way. I won't quibble for this patch.

Honestly, my expectation is that when HeapShared::is_loading_mapping_mode() == true, then HeapShared::is_loading() == true, and when is_loading_mapping_mode() == false, then is_loading() is undefined/dont-care value. In that sense, current code that checks only HeapShared::is_loading_mapping_mode() would have been correct already. But I am guessing you don't want to miss a bug when is_loading_mapping_mode() returns false, just because we have a lifecycle bug somewhere and loading mode is uninitialized.

Yes. We have had a few of those bugs at the end of the development cycle for the object streaming JEP.

OTOH, it is literally the same as checking is_loading() explicitly like your PR does, so it gains us nothing safety-wise, and only confuses ourselves. Maybe rethinking the state machinery a bit here would be a good cleanup.

I think Erik had it more like you suggest, but if I understood Ioi correctly he wanted things to be more explicit, and this is what we ended up with. I don't mind if someone wants to take a stab at restructuring this, but I'm not personally volunteering to do this. I would rather take the time to make other refactoring and renaming that we felt would benefit the heap sharing code, and we had hope to get to it after the JEP was delivered. However, the reality is that we're all prioritizing other work at the moment so I don't know if / when we'll get to that.

stefank · 2025-12-12T14:01:52Z

Thanks for the reviews! Tier1 testing passed.
/integrate

openjdk · 2025-12-12T14:02:56Z

Going to push as commit d854a04.
Since your change was applied there have been 42 commits pushed to the master branch:

4100143: 8373225: GenShen: More adaptive old-generation growth heuristics
a05d5d2: 8373579: Problem list compiler/runtime/Test7196199.java
180d8c1: 8372746: Some httpserver files could benefit from some formatting cleanup
... and 39 more: https://git.openjdk.org/jdk/compare/830c4d3b198597b6af7a21b708bd3a852af200d4...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-12-12T14:03:14Z

@stefank Pushed as commit d854a04.

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

8373411: Crash when PrintSharedArchiveAndExit is enabled but shared h…

4221e14

…eap is disabled

openjdk bot added the hotspot-runtime [email protected] label Dec 10, 2025

openjdk bot added the rfr Pull request is ready for review label Dec 10, 2025

iklam reviewed Dec 10, 2025

View reviewed changes

shipilev reviewed Dec 11, 2025

View reviewed changes

Review

a1dde92

shipilev approved these changes Dec 11, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Dec 11, 2025

iklam approved these changes Dec 11, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Dec 12, 2025

openjdk bot closed this Dec 12, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 12, 2025

8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled #28741

8373411: Crash when PrintSharedArchiveAndExit is enabled but shared heap is disabled #28741

Uh oh!

Conversation

stefank commented Dec 10, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

stefank commented Dec 10, 2025

Uh oh!

bridgekeeper bot commented Dec 10, 2025

Uh oh!

openjdk bot commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shipilev left a comment

Choose a reason for hiding this comment

Uh oh!

shipilev commented Dec 11, 2025

Uh oh!

stefank commented Dec 11, 2025

Uh oh!

stefank commented Dec 11, 2025

Uh oh!

shipilev commented Dec 11, 2025

Uh oh!

stefank commented Dec 11, 2025

Uh oh!

stefank commented Dec 12, 2025

Uh oh!

openjdk bot commented Dec 12, 2025

Uh oh!

openjdk bot commented Dec 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

stefank commented Dec 10, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Dec 10, 2025 •

edited

Loading

openjdk bot commented Dec 10, 2025 •

edited

Loading

mlbridge bot commented Dec 10, 2025 •

edited

Loading