RFR: 8305896: Alternative full GC forwarding [v41]

[Aleksey Shipilev]

On Wed, 10 May 2023 20:31:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The c...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Align fake-heap without GCC warnings (duh)

A few additional minor things:

src/hotspot/share/gc/shared/slidingForwarding.cpp line 152:

> 150:   // Search existing entry in chain starting at idx.
> 151:   for (FallbackTableEntry* entry = head; entry != nullptr; entry = entry->_next) {
> 152:     assert(entry->_from != from,"Don't re-forward entries into the fallback-table");

Suggestion:

    assert(entry->_from != from, "Don't re-forward entries into the fallback-table");

src/hotspot/share/gc/shared/slidingForwarding.hpp line 62:

> 60:  *                                                                    ^----- normal lock bits, would record "object is forwarded"
> 61:  *                                                                   ^------ fallback bit (explained below)
> 62:  *                                                                  ^------- alternate region select

Suggestion:

 *    [................................OOOOOOOOOOOOOOOOOOOOOOOOOOOOAFTT]
 *                                                                    ^----- normal lock bits, would record "object is forwarded"
 *                                                                  ^------- fallback bit (explained below)
 *                                                                 ^-------- alternate region select

test/hotspot/gtest/gc/shared/test_preservedMarks.cpp line 61:

> 59: #ifndef PRODUCT
> 60:   FlagSetting fs(UseAltGCForwarding, false);
> 61: #endif

So, would this test fail in release JDK, but when `UseAltGCForwarding` is `true`? If so, maybe do:


#ifndef PRODUCT
  FlagSetting fs(UseAltGCForwarding, false);
#else
  // Should not run this test with alt GC forwarding
  if (UseAltGCForwarding) return;
#endif

test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithG1.java line 44:

> 42:  * @requires vm.gc.G1
> 43:  * @requires vm.debug
> 44:  * @requires os.maxMemory > 8g

Why `>8g`? The test uses `-Xmx512m`.

test/hotspot/jtreg/gc/stress/systemgc/TestSystemGCWithSerial.java line 65:

> 63:  * @library /
> 64:  * @requires vm.gc.Serial
> 65:  * @requires vm.debug

This likely requires another requires:


 * @requires (vm.bits == "64") & (os.maxMemory >= 6G)

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13582#pullrequestreview-1422199824
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1191051839
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1191057460
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1190936600
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1190929583
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1190922619