RFR: 8305896: Alternative full GC forwarding [v39]
Roman Kennke
rkennke at openjdk.org
Tue May 9 16:29:34 UTC 2023
On Tue, 9 May 2023 16:15:08 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> @tschatzl's latest fix, cleanup and a test that checks unaligned heap problem
>
> src/hotspot/share/gc/shared/slidingForwarding.cpp line 166:
>
>> 164: // Set from and to in new or found entry.
>> 165: entry->_from = from;
>> 166: entry->_to = to;
>
> Does _from and _to change between lookups? In other words, if we first create a FallbackTableEntry and then next time find this existing FallbackTableEntry from the first lookup, shouldn't _from and _to be the same? The fact that setting _from and _to is done outside of the if, makes it look like they can and should mutate between lookups. But surely it will be the same values, or have I missed anything?
Objects should be forwarded only once. The exception is G1 serial compaction, which re-forwards objects. However, I believe they should initially be forwarded 'normally' (by normal sliding compaction), and then only re-forwarded once, at which point they should land in the fallback-hashtable. I need to check it, but I believe we may be able to simplify this code and assume (and assert) that objects have not yet been forwarded in the fallback-table. Good find! (BTW, the gtests that I added for this code take advantage of re-forwarding, so those would require a re-write)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1188853376
More information about the shenandoah-dev
mailing list