RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v2]

[Kelvin Nilsen]

On Wed, 9 Apr 2025 00:27:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 78:
>> 
>>> 76:   _live_data(0),
>>> 77:   _critical_pins(0),
>>> 78:   _mixed_candidate_garbage_words(0),
>> 
>> Do we need a new field to track this? During `final_mark`, we call `increase_live_data_alloc_words` to add `TAMS + top` to `_live_data` to account for objects allocated during mark. Could we "fix" `get_live_data` so that it always returned marked objects (counted by `increase_live_data_gc_words`) _plus_ `top - TAMS`. This way, the live data would not become stale after `final_mark` and we wouldn't have another field to manage. What do you think?
>
> This is a good idea.  Let me experiment with this.

My experiment with an initial attempt at this failed with over 60 failures.  The "problem" is that we often consult get_live_data() in contexts from which it is "not appropriate" to add (top- TAMS) to the atomic volatile ShenandoahHeapRegion::_live_data() .  I think most of these are asserts.  I have so far confirmed that there are at least two different places that need to be fixed.  Not sure how many total scenarios.

I'm willing to move forward with changes to the failing asserts to make this change work.  I think the code would be cleaner with your suggested refactor.  It just makes this PR a little more far-reaching than the original.

See the most recent commit on this PR to see the direction this would move us.  Let me know if you think I should move forward with more refactoring, or revert this most recent change.

Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2035784267