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