[master] RFR: Unconditionally preserve all marks during GC

Aleksey Shipilev shade at openjdk.java.net
Wed May 19 08:58:19 UTC 2021


On Tue, 18 May 2021 20:54:54 GMT, Roman Kennke <rkennke 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

I have questions about the asserts.

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?

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.

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

Changes requested by shade (Committer).

PR: https://git.openjdk.java.net/lilliput/pull/6


More information about the lilliput-dev mailing list