RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3]
William Kemper
wkemper at openjdk.org
Thu Nov 6 18:06:03 UTC 2025
On Thu, 6 Nov 2025 01:18:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>>
>> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots
>> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots
>> - Flush SATB buffers upon entering degenerated cycle when old marking is in progress
>>
>> This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier.
>> - Fix typo in comment
>> - Remove duplicate satb flush closure
>> - Only flush satb once during degenerated cycle
>> - Cleanup and comments
>> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots
>> - Fix assertion
>> - Oops, move inline definition out of ifdef ASSERT
>> - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 237:
>
>> 235: // also cases where the referent of a weak reference ends up in the SATB
>> 236: // and is later collected. In these cases the oop in the SATB buffer becomes
>> 237: // invalid and the _next_ cycle will crash during its marking phase. To
>
> Again I don't understand the concept of an SATB pointer to an object that was later collected? Are we talking about young objects that are subsequently processed by old marking because they weren't filtered out when they should be?
>
> I think that is probably the case here, but it would be good to clean up these comments to avoid this confusion.
Suppose we have a young collection running while the SATB barrier is active for old marking. The barrier will be enabled for the entirety of the young collection. Now, suppose we have a situation like this:
+--Young, CSet------+ +--Young, Regular----+
| | | |
| | | |
| A <--------------------+ B |
| | | |
| | | |
| | | |
| | | |
| | | |
+-------------------+ +--------------------+
If a mutator overwrites the pointer in `B`, the SATB barrier will enqueue object `A`. These are the objects we need to filter out.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2500196026
More information about the hotspot-gc-dev
mailing list