8364111: InstanceMirrorKlass iterators should handle CDS and hidden classes consistently #26477

shipilev · 2025-07-25T12:01:00Z

See the bug for more investigation. I think the root cause is already fixed in one of the InstanceMirrorKlass iterators, but not in the other one. Additionally, only one iterator handles the hidden classes. Also, there is a stale comment about CMS that apparently prevents us from asserting is_primitive, which is not relevant anymore.

So this PR commons out the metadata handling on both iterators, which fixes the GenShen+CDS bug, likely fixes hidden classes bug somewhere, and prevents the omission like this from happening again.

Additional testing:

Linux x86_64 server fastdebug, Generational Shenandoah + CDS bugs are not reproducing now
Linux x86_64 server fastdebug, tier1
Linux x86_64 server fastdebug, all

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

JDK-8364111: InstanceMirrorKlass iterators should handle CDS and hidden classes consistently (Bug - P4)

Reviewers

Coleen Phillimore (@coleenp - Reviewer) 🔄 Re-review required (review applies to 5e4153ae)
Thomas Stuefe (@tstuefe - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26477

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-07-25T12:02:06Z

👋 Welcome back shade! 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-07-25T12:03:02Z

@shipilev This change is no longer ready for integration - check the PR body for details.

openjdk · 2025-07-25T12:03:40Z

@shipilev 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 · 2025-07-25T13:00:43Z

Webrevs

coleenp

This looks like a good cleanup but need someone who knows GC better to also review.

/reviewers add 2

openjdk · 2025-07-25T14:57:02Z

@coleenp Usage: /reviewers <n> [<role>] where <n> is the number of required reviewers. If role is set, the reviewers need to have that project role. If omitted, role defaults to authors.

coleenp · 2025-07-25T14:57:24Z

/reviewers 2

openjdk · 2025-07-25T14:58:06Z

@coleenp
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

tstuefe · 2025-07-25T15:31:48Z

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp

+  } else {
+    // Klass is null means this has been a mirror for a primitive type
+    // that we do not need to follow as they are always strong roots.
+    assert(java_lang_Class::is_primitive(obj), "Sanity");


Question, since this assert is new:

When we create a mirror (java_lang_Class::allocate_mirror) during normal - non-shared - class loading, is there not a small time window where the mirror exists on the heap, but the Klass is still NULL? Could concurrent heap walkers not observe that?

Good point. We create the mirror then initialize the class, so a concurrent GC could see a null Klass pointer.

Actually, I now see this assert is tautological: java_lang_Class::is_primitive checks that java_class->metadata_field(_klass_offset) == nullptr, which is the same as pulling the Klass* with java_lang_Class::as_Klass and null-checking it, like we already just did. So really the assert is redundant and we can purge it.

But this also suggests that whatever interaction with GC exists, it affects current code as well. I think it works with concurrent GCs through a different mechanism: the classes loaded during the GC and their mirrors would be either treated as implicitly live (e.g. via SATB invariants), or need to be specially keep-alived (Shenandoah's IU mode did this, IIRC).

This is what old CMS comment tried to say, I think:

// However, we might get across a klass that just changed during CMS concurrent // marking if allocation occurred in the old generation. // // This is benign here, as we keep alive all CLDs that were loaded during the // CMS concurrent phase in the class loading, i.e. they will be iterated over // and kept alive during remark.

Pretty exhausted at this point, I'll mull over it after the weekend. But so far I think we are fine. Testing returns clean as well. If you can schedule some aggressive testing over the weekend, it would be helpful.

Wait, it's actually the other way around: we can see nullptr it our explicit check for a non-primitive class, stall, get to the assert, then discover that mirror is installed, and falsely fail the assert. Assert needs to be removed, did so in new commit. This also matches current behavior better.

Yes, I believe what we have now is correct. We cannot do anything here if Klass* backlink is not yet installed, and GC code needs to handle it separately. I think all GCs already do by e.g. keeping newly allocated classes alive. I polished the comment a bit.

tstuefe

The new comment is a lot better, thanks.

tstuefe · 2025-07-29T06:39:42Z

src/hotspot/share/oops/instanceMirrorKlass.inline.hpp

@@ -121,11 +124,7 @@ void InstanceMirrorKlass::oop_oop_iterate_bounded(oop obj, OopClosureType* closu

  if (Devirtualizer::do_metadata(closure)) {
    if (mr.contains(obj)) {


Unrelated, we could probably move mr.contains up to include InstanceKlass::oop_oop_iterate_bounded<T>(obj, closure, mr); to prevent the double check.

tstuefe · 2025-07-29T06:54:01Z

I wondered briefly whether the allowance ("CLD = null is okay for newly-loaded classes") should be also made in

jdk/src/hotspot/share/memory/iterator.inline.hpp

Lines 57 to 59 in 4669005

    
           } else { 
        
             assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); 
        
           }

But since we now handle mirror->referee Klass correctly in IMK, this only path affects oop->its Klass, and no instances exist yet for that Klass, right?

shipilev added 3 commits July 25, 2025 13:48

Fix

18a6a4f

Mark as inline as well

8460be7

Comments

5e4153a

openjdk bot added the hotspot [email protected] label Jul 25, 2025

shipilev marked this pull request as ready for review July 25, 2025 12:55

openjdk bot added the rfr Pull request is ready for review label Jul 25, 2025

coleenp approved these changes Jul 25, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 25, 2025

openjdk bot removed the ready Pull request is ready to be integrated label Jul 25, 2025

tstuefe reviewed Jul 25, 2025

View reviewed changes

shipilev added 2 commits July 25, 2025 19:23

Drop assert, more discussion

bc85328

Better comment

40761ec

tstuefe approved these changes Jul 29, 2025

View reviewed changes

tstuefe reviewed Jul 29, 2025

View reviewed changes

		@@ -121,11 +124,7 @@ void InstanceMirrorKlass::oop_oop_iterate_bounded(oop obj, OopClosureType* closu

		if (Devirtualizer::do_metadata(closure)) {
		if (mr.contains(obj)) {

8364111: InstanceMirrorKlass iterators should handle CDS and hidden classes consistently #26477

Are you sure you want to change the base?

8364111: InstanceMirrorKlass iterators should handle CDS and hidden classes consistently #26477

Conversation

shipilev commented Jul 25, 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!

bridgekeeper bot commented Jul 25, 2025

Uh oh!

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

Uh oh!

Uh oh!

openjdk bot commented Jul 25, 2025

Uh oh!

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

Uh oh!

Webrevs

Uh oh!

coleenp left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Jul 25, 2025

Uh oh!

coleenp commented Jul 25, 2025

Uh oh!

openjdk bot commented Jul 25, 2025

Uh oh!

tstuefe Jul 25, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Jul 25, 2025

Choose a reason for hiding this comment

Uh oh!

shipilev Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shipilev Jul 25, 2025

Choose a reason for hiding this comment

Uh oh!

shipilev Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shipilev Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shipilev Jul 28, 2025

Choose a reason for hiding this comment

Uh oh!

tstuefe left a comment

Choose a reason for hiding this comment

Uh oh!

tstuefe Jul 29, 2025

Choose a reason for hiding this comment

Uh oh!

tstuefe commented Jul 29, 2025

Uh oh!

Uh oh!

shipilev commented Jul 25, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Jul 25, 2025 •

edited

Loading

mlbridge bot commented Jul 25, 2025 •

edited

Loading

shipilev Jul 25, 2025 •

edited

Loading

shipilev Jul 25, 2025 •

edited

Loading

shipilev Jul 25, 2025 •

edited

Loading