[master] RFR: Unconditionally preserve all marks during GC
Roman Kennke
rkennke at openjdk.java.net
Wed May 19 10:30:25 UTC 2021
On Wed, 19 May 2021 08:53:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> When storing the Klass* in the object header, we need to preserve all marks during GC, because otherwise we'd be loosing the Klass*.
>>
>> This means that the PreservedMarks structure is repurposed as a full (reverse) forwarding table. Reverse because instead of mapping object->forwardee, and leaving the mark alone, it maps object->mark and stores the forwardee in the header, which might be a better idea because it means we can have a most compact table.
>>
>> Shenandoah doesn't have this problem, except during full-GC, and ZGC has its own forwarding table.
>>
>> This change will likely affect performance, but I haven't checked by how much, yet. It's probably more useful to see this in the context of actually reduced header.
>> Testing:
>> - [x] tier1
>> - [ ] tier2
>
> src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 120:
>
>> 118: // fixed when restoring the preserved marks.
>> 119: assert(object->mark() == markWord::prototype_for_klass(object->klass()) || // Correct mark
>> 120: object->mark_must_be_preserved() || // Will be restored by PreservedMarksSet
>
> It would seem this assert checks that mark is correct or it would be preserved. Since all marks are now preserved, this assert is basically `true` at all times? If you just drop `object->mark_must_be_preserved()`, it should be failing with forwarded objects, no?
This block concerns about non-forwarded objects because forwarded objects are handled above.
> src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp line 83:
>
>> 81: // Not forwarded, return current reference.
>> 82: assert(obj->mark() == markWord::prototype_for_klass(obj->klass()) || // Correct mark
>> 83: obj->mark_must_be_preserved() || // Will be restored by PreservedMarksSet
>
> Same as above.
Yeah, same as above ;-)
-------------
PR: https://git.openjdk.java.net/lilliput/pull/6
More information about the lilliput-dev
mailing list