RFR: 8305896: Alternative full GC forwarding [v10]

[Roman Kennke]

On Fri, 28 Apr 2023 09:02:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix minimal build
>
> src/hotspot/share/gc/shared/slidingForwarding.cpp line 49:
> 
>> 47:     _num_regions = 1;
>> 48:     _region_size_words_shift = log2i_exact(round_up_power_of_2(heap_size_words));
>> 49:   }
> 
> This feels like something that Serial GC code should be doing when initializing the forwarding.

Yes but that means to create a dependency that I would rather like to avoid: Serial GC would have to know about the maximum encodable range of slidingForwarding (and therefore about sliding forwarding to begin with). OTOH, the way I did it was to create the dependency in the inverse direction. A way out might be to not do that optimization, but it seems rather important: the heap < 2GB seems fairly common with Serial GC. Hmmm

> test/hotspot/gtest/gc/shared/test_slidingForwarding.cpp line 63:
> 
>> 61:   ASSERT_EQ(sf.forwardee(obj1), obj2);
>> 62: 
>> 63:   sf.forward_to(obj1, obj3);
> 
> Wait, so this implies the forwardings can be overwritten? I understand this need for the test, but wouldn't that be a lifecycle error for product code? Once forwarding is done, it must be only reset, no?

As far as I understand, GC serial compaction can re-forward already forwarded objects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180283786
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180280730