8352185: Shenandoah: Invalid logic for remembered set verification #24092

pengxiaolong · 2025-03-18T00:19:35Z

There are some scenarios in which GenShen may have improper remembered set verification logic:

Concurrent young cycles following a Full GC:

In the end of ShenandoahFullGC, it resets bitmaps for the entire heap w/o resetting marking context to be incomplete, but ShenandoahVerifier has code like below to get a complete old marking context for remembered set verification

ShenandoahVerifier  
ShenandoahMarkingContext* ShenandoahVerifier::get_marking_context_for_old() {
  shenandoah_assert_generations_reconciled();
  if (_heap->old_generation()->is_mark_complete() || _heap->gc_generation()->is_global()) {
    return _heap->complete_marking_context();
  }
  return nullptr;
}

For the concurrent young GC cycles after a full GC, the old marking context used for remembered set verification is stale, and may cause unexpected result.

For the impl of ShenandoahVerifier::get_marking_context_for_old mentioned above, it always return a marking context for global GC, but marking bitmaps is already reset before before init-mark, ShenandoahVerifier::help_verify_region_rem_set always skip verification in this case.
ShenandoahConcurrentGC always clean remembered set read table, but only swap read/write table when gc generation is young, this issue causes remembered set verification before init-mark to use a completely clean remembered set, but it is covered by issue 2.
After concurrent young cycle evacuates objects from a young region, it update refs using marking bitmaps from marking context, therefore it won't update references of dead old objects(is_marked(obj) is false: obj is not marking strong/weak and it is below tams). In this case, if the next cycle if global concurrent GC, remembered set can't be verified before init-mark because of the dead pointers.

Solution

After a full GC, always set marking completeness flag to false after reseting the marking bitmaps.
Because there could be dead pointers in old gen were not updated to point to new address after evacuation and refs update, we should disable rem-set validation before init-mark&update-refs if old marking context is incomplete.

Test

make test TEST=hotspot_gc_shenandoah
GHA

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

Issues

JDK-8352185: Shenandoah: Invalid logic for remembered set verification (Bug - P3)
JDK-8345399: GenShen: Error: Verify init-mark remembered set violation; clean card should be dirty (Bug - P3)

Reviewers

Kelvin Nilsen (@kdnilsen - Committer) Review applies to 16494d48
William Kemper (@earthling-amzn - Reviewer) Review applies to 16494d48
Y. Srinivas Ramakrishna (@ysramakrishna - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24092

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

Using diff file

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

Using Webrev

Link to Webrev Comment

…rly rebuilt through marking.

bridgekeeper · 2025-03-18T00:20:36Z

👋 Welcome back xpeng! 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-03-18T00:21:30Z

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

8352185: Shenandoah: Invalid logic for remembered set verification
8345399: GenShen: Error: Verify init-mark remembered set violation; clean card should be dirty

Reviewed-by: ysr, kdnilsen, wkemper

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

3d2c3cd: 8352970: Remove unnecessary Windows version check in Win32ShellFolderManager2
c70ad6a: 8352906: stdout/err.encoding on Windows set by incorrect Win32 call
da3bb06: 8352685: Opensource JInternalFrame tests - series2
d809033: 8341775: Duplicate manifest files are removed by jarsigner after signing
a269bef: 8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64
c029220: 8352896: LambdaExpr02.java runs wrong test class
c0b61d3: 8352680: Opensource few misc swing tests
3e9a7a4: 8353063: make/ide/vscode: Invalid Configuration Values
8ef7832: 8350471: Unhandled compilation bailout in GraphKit::builtin_throw
ddf326b: 8346888: [ubsan] block.cpp:1617:30: runtime error: 9.97582e+36 is outside the range of representable values of type 'int'
... and 131 more: https://git.openjdk.org/jdk/compare/74df384a9870431efb184158bba032c79c35356e...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@kdnilsen, @earthling-amzn, @ysramakrishna) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

openjdk · 2025-03-18T00:22:03Z

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

hotspot-gc
shenandoah

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.

pengxiaolong · 2025-03-18T00:23:01Z

/issue JDK-8352185

openjdk · 2025-03-18T00:23:16Z

@pengxiaolong This issue is referenced in the PR title - it will now be updated.

kdnilsen · 2025-03-18T01:25:11Z

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp

  assert(!heap->has_forwarded_objects(), "No forwarded objects on this path");

  if (heap->mode()->is_generational()) {
-    if (_generation->is_young()) {


I think we do not want to change this code. We only swap remembered set for young-gen because gen will scan the remset and reconstruct it with more updated information. For a global GC, we do not scan the remset and do not reconstruct it. If we swap here, we will lose the information that is currently within the remset.

Thanks for for explanation, I have been reading and trying the understand how the remembered set works in GenShen. I wasn't sure whether this is actually right.

In generational mode, if the GC cycle is global, the read table is already cleaned during reset phase, so remembered set verification from verify_before_concmark and verify_before_update_refs shouldn't work properly, I think the remembered set verification before mark and update references should be disabled, what do you think? Meanwhile, there is no need to clean read table during global cycle in generational mode.

Ok. So we will always swap card tables, but we'll do it after verify-before-mark. To clarify the intention, after we swap card table, the write-table is all clean, and the read table holds whatever had been gathered prior to the start of GC. Young and bootstrap collection will update the write card table as a side effect of remembered set scanning. Global collection will update the card table as a side effect of global marking of old objects.

I'd leave a comment to this effect (along the lines of Kelvin's last comment) here. Did we measure the impact of this change on performance? In particular it would seem that the number of dirty old cards might now reduce after a global gc compared to before this change.

Ideally, this would be a change that would go in on its own. (There is no impact on correctness, since in the absence of this change, the dirty card set is an over-approximation.)

It is a bit hard to measure the impact on performance I think, but given the rem-set is more accurate, there shouldn't be any performance regression.

I was suggesting looking to see if normal perf measures showed any improvements. E.g. if you ran say SPECjbb and compared the remset scan times for the minor GC's that followed global collections.

I have run h2 benchmark, here is the remembered set scan times after a global GC, it does seem to improve remembered set scan time in this case:

PR version:

[2025-03-21T07:35:41.801+0000][10.292s][19715][info ][gc ] GC(6) Concurrent remembered set scanning 13.069ms [2025-03-21T07:35:48.088+0000][16.579s][19715][info ][gc ] GC(9) Concurrent remembered set scanning 5.537ms [2025-03-21T07:35:56.610+0000][25.101s][19715][info ][gc ] GC(14) Concurrent remembered set scanning 6.186ms [2025-03-21T07:36:03.967+0000][32.459s][19715][info ][gc ] GC(18) Concurrent remembered set scanning 9.562ms [2025-03-21T07:36:11.234+0000][39.725s][19715][info ][gc ] GC(22) Concurrent remembered set scanning 2.591ms [2025-03-21T07:36:17.303+0000][45.794s][19715][info ][gc ] GC(25) Concurrent remembered set scanning 0.999ms [2025-03-21T07:36:25.647+0000][54.139s][19715][info ][gc ] GC(30) Concurrent remembered set scanning 1.665ms [2025-03-21T07:36:32.790+0000][61.281s][19715][info ][gc ] GC(33) Concurrent remembered set scanning 2.851ms [2025-03-21T07:36:40.241+0000][68.732s][19715][info ][gc ] GC(36) Concurrent remembered set scanning 0.716ms [2025-03-21T07:36:47.440+0000][75.931s][19715][info ][gc ] GC(39) Concurrent remembered set scanning 1.932ms

master:

[2025-03-21T07:34:04.978+0000][10.765s][17923][info ][gc ] GC(6) Concurrent remembered set scanning 22.813ms [2025-03-21T07:34:11.250+0000][17.038s][17923][info ][gc ] GC(9) Concurrent remembered set scanning 14.457ms [2025-03-21T07:34:18.692+0000][24.480s][17923][info ][gc ] GC(14) Concurrent remembered set scanning 4.972ms [2025-03-21T07:34:26.033+0000][31.820s][17923][info ][gc ] GC(18) Concurrent remembered set scanning 9.134ms [2025-03-21T07:34:34.416+0000][40.203s][17923][info ][gc ] GC(22) Concurrent remembered set scanning 3.655ms [2025-03-21T07:34:42.180+0000][47.967s][17923][info ][gc ] GC(26) Concurrent remembered set scanning 3.253ms [2025-03-21T07:34:49.371+0000][55.168s][17923][info ][gc ] GC(29) Concurrent remembered set scanning 1.615ms [2025-03-21T07:34:56.592+0000][62.396s][17923][info ][gc ] GC(32) Concurrent remembered set scanning 1.570ms [2025-03-21T07:35:03.766+0000][69.575s][17923][info ][gc ] GC(35) Concurrent remembered set scanning 1.040ms [2025-03-21T07:35:10.941+0000][76.753s][17923][info ][gc ] GC(38) Concurrent remembered set scanning 1.947ms

May be as intended earlier, leave a documentation comment between lines 697 & 698 along the lines of Kelvin's comment:

// After we swap card table below, the write-table is all clean, and the read table holds // cards dirty prior to the start of GC. Young and bootstrap collection will update // the write card table as a side effect of remembered set scanning. Global collection will // update the card table as a side effect of global marking of old objects.

Sorry, I added comments as you suggested but forgot to push.Now the comment has been added.

kdnilsen · 2025-03-18T01:36:03Z

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

  shenandoah_assert_generations_reconciled();
-  if (_heap->old_generation()->is_mark_complete() || _heap->gc_generation()->is_global()) {
-    return _heap->complete_marking_context();
+  if (_heap->old_generation()->is_mark_complete()) {


In the case that this is an global GC, we know that old-generation()->is_mark_complete() by virtue of the current program counter, I assume. (We would only ask for the old marking context if global marking were already finished.) In the case that we are doing a global GC cycle, I'm guessing that we do not set is-mark-complete for the old generation. So that's why I believe you need to keep the condition as originally written.

If it is global GC in generational mode, old-generation()->is_mark_complete() is always false after reset and before mark because bitmaps of the entire heap including old gen has been reset during concurrent reset phase, so old mark is not finished in when verify_before_concmark is called. The marking context return by this method is only used for remembered set verification, but as I pointed out in the first comments, we shouldn't do remembered set verification in such case because the rem-set read table is already cleaned/stale.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp

…urrent global GC in generational mode

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

mlbridge · 2025-03-18T22:18:43Z

Webrevs

kdnilsen

Can we confirm that this addresses JBS issue with further testing before integration?

kdnilsen · 2025-03-18T23:48:53Z

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp

  assert(!heap->has_forwarded_objects(), "No forwarded objects on this path");

  if (heap->mode()->is_generational()) {
-    if (_generation->is_young()) {


Ok. So we will always swap card tables, but we'll do it after verify-before-mark. To clarify the intention, after we swap card table, the write-table is all clean, and the read table holds whatever had been gathered prior to the start of GC. Young and bootstrap collection will update the write card table as a side effect of remembered set scanning. Global collection will update the card table as a side effect of global marking of old objects.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp

ysramakrishna · 2025-03-19T00:35:39Z

Can you sync w/master so GHA (& problem lists) is more uptodate. Thanks!

pengxiaolong · 2025-03-19T00:45:11Z

Can you sync w/master so GHA (& problem lists) is more uptodate. Thanks!

Done, now waiting for GHS to rerun, thanks.

… old generation.

openjdk · 2025-03-20T02:33:04Z

@pengxiaolong this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8345399-v3
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

…399-v3

…mplete

earthling-amzn

Couple of nits.

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp

kdnilsen

Thanks for the refinements. LGTM.

earthling-amzn

Do we think this will fix https://bugs.openjdk.org/browse/JDK-8345399, should we add it as an issue to this PR?

pengxiaolong · 2025-03-25T23:29:02Z

Do we think this will fix https://bugs.openjdk.org/browse/JDK-8345399, should we add it as an issue to this PR?

It will likely fix the JDK-8345399, I mentioned it in JBS. will see if I can get a ppc64le hardware to verify this week.

ysramakrishna

I think the change can be pushed as is, but I am not convinced that the verification can't be tightened when old marking information is missing as long as we have a valid TAMS and there are no unparsable objects (which should only happen when coalease-&-fill has been interrupted, leaving dead objects with x-gen pointers that would cause false positives or upon class unloading when dead objects may end up being unparsable). The current condition of skipping verification when old bit maps are cleared seems to miss verification opportunities that would be valid after a completed C&F.

Left some related comments, but I won't hold back this PR further. The tightening can be done subsequently (and I am happy to pick that up afterwards as needed).

Thanks for your patience with my tardy and long-winded reviews! :-)

ysramakrishna · 2025-03-26T00:30:55Z

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp

  assert(!heap->has_forwarded_objects(), "No forwarded objects on this path");

  if (heap->mode()->is_generational()) {
-    if (_generation->is_young()) {


May be as intended earlier, leave a documentation comment between lines 697 & 698 along the lines of Kelvin's comment:

// After we swap card table below, the write-table is all clean, and the read table holds // cards dirty prior to the start of GC. Young and bootstrap collection will update // the write card table as a side effect of remembered set scanning. Global collection will // update the card table as a side effect of global marking of old objects.

ysramakrishna · 2025-03-26T00:44:18Z

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

-    verify_at_safepoint(
+  VerifyRememberedSet verify_remembered_set = _verify_remembered_before_marking;
+  if (_heap->mode()->is_generational() &&
+      !_heap->old_generation()->is_mark_complete()) {


Why not the following stronger condition to skip verification? My sense is that the only case we cannot verify is if we do not have marking info and old gen has been left "unparsable" (because of an incomplete/interrupted C&F which may have us look at dead objects -- that are either unparsable because of class unloading, or are parsable but hold cross-gen pointers). In all other cases, we can do a safe and complete verification.

is_generational() && !old_gen->is_mark_complete() && !old_gen->is_parsable()

We may not need to worry about it, old_gen becomes not parsable in class unloading phase of a global concurrent GC, marking is already done for the global including old gen, there should be always complete marking for old when old gen is not parsable.

ysramakrishna · 2025-03-26T00:47:41Z

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

 void ShenandoahVerifier::verify_before_update_refs() {
+  VerifyRememberedSet verify_remembered_set = _verify_remembered_before_updating_references;
+  if (_heap->mode()->is_generational() &&
+      !_heap->old_generation()->is_mark_complete()) {


Same comment re stronger condition as previous one above.

ysramakrishna

🚢

pengxiaolong · 2025-03-28T00:51:47Z

I have reproduced the bug https://bugs.openjdk.org/browse/JDK-8345399 on ppc64le hardware with tip, crash happens in a young cycle after a full GC, which is one of the problems I'm trying to fix in this PR:

[13.990s][info][gc,start       ] GC(101) Pause Full                                                                                                                                                                                                
[13.990s][info][gc,task        ] GC(101) Using 4 of 4 workers for full gc                                                                                                                                                                          
[13.990s][info][gc,start       ] GC(101) Verify Before Full GC, Level 4                                                                                                                                                                            
[13.998s][info][gc             ] GC(101) Verify Before Full GC, Level 4 (22772 reachable, 0 marked)                                                                                                                                                
[13.998s][info][gc,phases,start] GC(101) Phase 1: Mark live objects                                                                                                                                                                                
[14.003s][info][gc,ref         ] GC(101) Clearing All SoftReferences                                                                                                                                                                               
[14.003s][info][gc,ref         ] GC(101) Clearing All SoftReferences                                                                                                                                                                               
[14.009s][info][gc,ref         ] GC(101) Encountered references: Soft: 49, Weak: 101, Final: 0, Phantom: 8                                                                                                                                         
[14.009s][info][gc,ref         ] GC(101) Discovered  references: Soft: 31, Weak: 39, Final: 0, Phantom: 8                                                                                                                                          
[14.009s][info][gc,ref         ] GC(101) Enqueued    references: Soft: 0, Weak: 0, Final: 0, Phantom: 0                                                                                                                                            
[14.012s][info][gc,phases      ] GC(101) Phase 1: Mark live objects 13.674ms                                                                                                                                                                       
[14.012s][info][gc,phases,start] GC(101) Phase 2: Compute new object addresses                                                                                                                                                                     
[14.026s][info][gc,phases      ] GC(101) Phase 2: Compute new object addresses 14.166ms                                                                                                                                                            
[14.026s][info][gc,phases,start] GC(101) Phase 3: Adjust pointers                                                                                                                                                                                  
[14.030s][info][gc,phases      ] GC(101) Phase 3: Adjust pointers 3.626ms                                                                                                                                                                          
[14.030s][info][gc,phases,start] GC(101) Phase 4: Move objects                                                                                                                                                                                     
[14.128s][info][gc,phases      ] GC(101) Phase 4: Move objects 98.264ms                                                                                                                                                                            
[14.128s][info][gc,phases,start] GC(101) Phase 5: Full GC epilog                                                                                                                                                                                   
[14.146s][info][gc,ergo        ] GC(101) Transfer 234 region(s) from Old to Young, yielding increased size: 790M                                                                                                                                   
[14.146s][info][gc,ergo        ] GC(101) FullGC done: young usage: 450M, old usage: 231M                                                                                                                                                           
[14.146s][info][gc,free        ] Free: 296M, Max: 512K regular, 296M humongous, Frag: 0% external, 0% internal; Used: 0B, Mutator Free: 592 Collector Reserve: 40959K, Max: 512K; Used: 16B Old Collector Reserve: 1307K, Max: 511K; Used: 740K    
[14.146s][info][gc,ergo        ] GC(101) After Full GC, successfully transferred 0 regions to none to prepare for next gc, old available: 1307K, young_available: 296M                                                                             
[14.146s][info][gc,barrier     ] GC(101) Cleaned read_table from 0x0000754a50290000 to 0x0000754a5048ffff                                                                                                                                          
[14.146s][info][gc,barrier     ] GC(101) Current write_card_table: 0x0000754a4fc90000                                                                                                                                                              
[14.148s][info][gc,phases      ] GC(101) Phase 5: Full GC epilog 20.265ms                                                                                                                                                                          
[14.148s][info][gc,start       ] GC(101) Verify After Full GC, Level 4                                                                                                                                                                             
[14.182s][info][gc             ] GC(101) Verify After Full GC, Level 4 (22664 reachable, 125 marked)                                                                                                                                               
[14.182s][info][gc,ergo        ] GC(101) At end of Full GC: GCU: 6.9%, MU: 9.9% during period of 0.261s                                                                                                                                            
[14.182s][info][gc,ergo        ] GC(101) At end of Full GC: Young generation used: 450M, used regions: 454M, humongous waste: 3532K, soft capacity: 1024M, max capacity: 790M, available: 296M                                                     
[14.182s][info][gc,ergo        ] GC(101) At end of Full GC: Old generation used: 231M, used regions: 234M, humongous waste: 1654K, soft capacity: 0B, max capacity: 234M, available: 1307K                                                         
[14.182s][info][gc,ergo        ] GC(101) Good progress for free space: 296M, need 10485K                                                                                                                                                           
[14.182s][info][gc,ergo        ] GC(101) Good progress for used space: 148M, need 512K                                                                                                                                                             
[14.182s][info][gc             ] GC(101) Pause Full 829M->681M(1024M) 192.311ms                                                                                                                                                                    
...
[14.196s][info][gc             ] Trigger (Young): Free (65536K) is below minimum threshold (80895K)
[14.196s][info][gc,free        ] Free: 65536K, Max: 512K regular, 65536K humongous, Frag: 0% external, 0% internal; Used: 0B, Mutator Free: 128 Collector Reserve: 40959K, Max: 512K; Used: 16B Old Collector Reserve: 1307K, Max: 511K; Used: 740K
[14.196s][info][gc,ergo        ] GC(102) Start GC cycle (Young)
[14.196s][info][gc,start       ] GC(102) Concurrent reset (Young)
[14.196s][info][gc,task        ] GC(102) Using 2 of 4 workers for Concurrent reset (Young)
[14.196s][info][gc,ergo        ] GC(102) Pacer for Reset. Non-Taxable: 1024M
Allocated: 732 Mb
Allocated: 699 Mb
Allocated: 715 Mb
[14.200s][info][gc,thread      ] Cancelling GC: unknown GCCause
[14.200s][info][gc             ] Failed to allocate Shared, 61709K
[14.202s][info][gc             ] GC(102) Concurrent reset (Young) 6.371ms
[14.203s][info][gc,barrier     ] GC(102) Cleaned read_table from 0x0000754a50080000 to 0x0000754a5027ffff
[14.203s][info][gc,start       ] GC(102) Pause Init Mark (Young)
[14.203s][info][gc,task        ] GC(102) Using 4 of 4 workers for init marking
[14.205s][info][gc,barrier     ] GC(102) Current write_card_table: 0x0000754a4fa80000
[14.205s][info][gc,start       ] GC(102) Verify Before Mark, Level 4
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/xlpeng/repos/jdk/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:1270), pid=2167519, tid=2167538
#  Error: Verify init-mark remembered set violation; clean card, it should be dirty.

Referenced from:
  interior location: 0x00000000c00c2bfc
  inside Java heap
    not in collection set
  region: |    1|R  |O|BTE     c0080000,     c00c2c78,     c0100000|TAMS     c0080000|UWM     c00c2c78|U   267K|T     0B|G     0B|P     0B|S   267K|L   267K|CP   0

Object:
  0x00000000e8c00000 - klass 0x000001df001abfa0 [I
    not allocated after mark start
    not after update watermark
    not marked strong
    not marked weak
    not in collection set
  age: 0
  mark: mark(is_unlocked no_hash age=0)
  region: | 1304|H  |Y|BTE     e8c00000,     e8c80000,     e8c80000|TAMS     e8c80000|UWM     e8c80000|U   512K|T     0B|G     0B|P     0B|S   512K|L     0B|CP   0

Forwardee:
  (the object itself)

I'll run the same test to confirm whether this PR fix the bug.

pengxiaolong · 2025-03-28T01:03:04Z

/issue add JDK-8345399

openjdk · 2025-03-28T01:03:31Z

@pengxiaolong
Adding additional issue to issue list: 8345399: GenShen: Error: Verify init-mark remembered set violation; clean card should be dirty.

pengxiaolong · 2025-03-29T00:32:24Z

/integrate

openjdk · 2025-03-29T00:32:58Z

@pengxiaolong
Your change (at version e11c6fc) is now ready to be sponsored by a Committer.

ysramakrishna · 2025-03-31T18:12:37Z

/sponsor

openjdk · 2025-03-31T18:13:31Z

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

3e96f5c: 8351366: Remove the java.security.debug=scl option
4247744: 8351435: Change the default Console implementation back to the built-in one in java.base module
9c06dcb: 8349583: Add mechanism to disable signature schemes based on their TLS scope
cd5a43a: 8353126: Open source events tests batch1
e4e6278: 8346129: Simplify EdDSA & XDH curve name usage
7a2e198: 8352277: java.security documentation: incorrect regex syntax describing "usage" algorithm constraint
b7ca76e: 8353235: Test jdk/jfr/api/metadata/annotations/TestPeriod.java fails with IllegalArgumentException
bbd5b17: 8339280: jarsigner -verify performs cross-checking between CEN and LOC
d4d1835: 8352860: Open source events tests batch0
c9c3c15: 8330598: java/net/httpclient/Http1ChunkedTest.java fails with java.util.MissingFormatArgumentException: Format specifier '%s'
... and 151 more: https://git.openjdk.org/jdk/compare/74df384a9870431efb184158bba032c79c35356e...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-03-31T18:13:40Z

@ysramakrishna @pengxiaolong Pushed as commit 4d1de46.

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

pengxiaolong added 2 commits March 12, 2025 00:38

Initial works

d7d0f30

Always swap card table in generational mode so the table can be prope…

7f87ab7

…rly rebuilt through marking.

openjdk bot added hotspot-gc [email protected] shenandoah [email protected] labels Mar 18, 2025

kdnilsen reviewed Mar 18, 2025

View reviewed changes

pengxiaolong added 2 commits March 18, 2025 00:37

Only clean rem-set read table in young gc; not verify rem-set in conc…

d55f9a1

…urrent global GC in generational mode

Set mark incomplete after ShenandoahMCResetCompleteBitmapTask

45d58df

earthling-amzn reviewed Mar 18, 2025

View reviewed changes

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Outdated Show resolved Hide resolved

Clean and rebuild rem-set in global gc

5a94b14

pengxiaolong changed the title ~~8352185: Shenandoah: Invalid logic for remembered set verification before init-mark~~ 8352185: Shenandoah: Invalid logic for remembered set verification Mar 18, 2025

pengxiaolong marked this pull request as ready for review March 18, 2025 22:14

openjdk bot added the rfr Pull request is ready for review label Mar 18, 2025

kdnilsen approved these changes Mar 19, 2025

View reviewed changes

Address review comments

021f2fe

Merge branch 'openjdk:master' into JDK-8345399-v3

4726b87

remembered set can't be verified w/o complete old marking or parsable…

f16dd72

… old generation.

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Mar 20, 2025

Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8345…

6c420c4

…399-v3

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Mar 20, 2025

pengxiaolong added 2 commits March 19, 2025 20:45

Fix test failure

3947f36

set old gen parsable to false when complete mixed evacuations

f0e8d69

pengxiaolong added 2 commits March 20, 2025 11:30

Not verify remembered set w/o parseable old gen when old mark is inco…

feceef3

…mplete

Fix wrong comments

39707d1

earthling-amzn suggested changes Mar 20, 2025

View reviewed changes

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Outdated Show resolved Hide resolved

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp Outdated Show resolved Hide resolved

pengxiaolong added 3 commits March 20, 2025 13:42

Use decode_raw_not_null instead of decode_raw

27cc142

Not validate remembered set w/o complete old marking

73e95e8

tide up

16494d4

kdnilsen approved these changes Mar 25, 2025

View reviewed changes

earthling-amzn approved these changes Mar 25, 2025

View reviewed changes

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

ysramakrishna approved these changes Mar 26, 2025

View reviewed changes

Add comments

e11c6fc

openjdk bot removed the ready Pull request is ready to be integrated label Mar 26, 2025

ysramakrishna approved these changes Mar 26, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 26, 2025

openjdk bot added the sponsor Pull request is ready to be sponsored label Mar 29, 2025

openjdk bot added the integrated Pull request has been integrated label Mar 31, 2025

openjdk bot closed this Mar 31, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Mar 31, 2025

pengxiaolong mentioned this pull request Apr 4, 2025

8351091: Shenandoah: global marking context completeness is not accurately maintained #23886

Closed

6 tasks

8352185: Shenandoah: Invalid logic for remembered set verification #24092

8352185: Shenandoah: Invalid logic for remembered set verification #24092

Uh oh!

Conversation

pengxiaolong commented Mar 18, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Solution

Test

Progress

Issues

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Mar 18, 2025

Uh oh!

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

Uh oh!

Uh oh!

openjdk bot commented Mar 18, 2025

Uh oh!

pengxiaolong commented Mar 18, 2025

Uh oh!

openjdk bot commented Mar 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pengxiaolong Mar 18, 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!

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!

Choose a reason for hiding this comment

Uh oh!

pengxiaolong Mar 18, 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!

Uh oh!

Uh oh!

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

Uh oh!

Webrevs

Uh oh!

kdnilsen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ysramakrishna commented Mar 19, 2025

Uh oh!

pengxiaolong commented Mar 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Mar 20, 2025

Uh oh!

earthling-amzn left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kdnilsen left a comment

Choose a reason for hiding this comment

Uh oh!

pengxiaolong commented Mar 18, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Mar 18, 2025 •

edited

Loading

pengxiaolong Mar 18, 2025 •

edited

Loading

pengxiaolong Mar 18, 2025 •

edited

Loading

mlbridge bot commented Mar 18, 2025 •

edited

Loading

pengxiaolong commented Mar 19, 2025 •

edited

Loading