RFR: Enable remembered set verification during global collections

William Kemper wkemper at openjdk.java.net
Wed Sep 8 22:04:41 UTC 2021


On Wed, 8 Sep 2021 20:50:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> There are two sets of changes here:
>>  * Fixes to the verifier itself to enable remembered set verification during global collection
>>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
>> 
>> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2202:
> 
>> 2200:         } else if (r->affiliation() == ShenandoahRegionAffiliation::OLD_GENERATION) {
>> 2201:           if (_heap->active_generation()->generation_mode() == GLOBAL) {
>> 2202:             _heap->marked_object_oop_iterate(r, &cl, update_watermark);
> 
> In the original code, we used the same iterator over marked objects for both coalescing and filling and for updating references.  That is "more efficient" than this new approach in that we make one pass instead of two over all objects in all heap regions.  I understand that there was a bug in how that is implemented, apparently, because this new version of the code has fewer crashes than the original.  Nevertheless, would like to have a comment here that suggests we might explore a way to consolidate the efforts at some future time, especially if we detect performance regressions with this new approach.

I'll try putting the 'fill-after-final-mark' on the code path that skips updates references and restoring this code. That way, we'll do one or the other, but not both.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2639:
> 
>> 2637:         while (obj_addr < t) {
>> 2638:           oop obj = oop(obj_addr);
>> 2639:           // ctx->is_marked() returns true if mark bit set or if obj above TAMS.
> 
> The reason original comment said "TAMS not relevant here" is because this verification occurs at init_mark.  There have been no allocations above TAMS at this execution point.  (Or if there is, maybe add a comment to explain how that comes to be.)

Will restore original comment.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64


More information about the shenandoah-dev mailing list