RFR: 8272773: Investigate making card table size configurable [v3]

[Thomas Schatzl]

On Fri, 8 Oct 2021 20:16:45 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable
>  - Changes as per the first set of comments

The change looks good now (keeping in mind that for some questions we are waiting for a second reviewer to chime in), however there are some things we need to do first:

* complete testing; while I have pushed the change through our perf test suite with no statistically significant regressions when using compiled-in 512 bytes card size vs. configurable 512 bytes card size, and ran with different (smaller) card sizes I would like to confirm the improvements you reported for the 1024 bytes case on specjbb2015, and analyze a few of the particular results. This will take a bit.

* for the new product flag (if we make it product, I am going to ask about this internally) we need a CSR completed before pushing. I started one at https://bugs.openjdk.java.net/browse/JDK-8275142, please have a look.
If we decide to make this non-product, then we can just close the CSR again.

* it would be nice to not be required to amend the CSR later to fix the bounds of the `GCCardSizeInBytes` flag (when it stays a product flag) when G1 supports different heap region sizes > 32M.
There is already a draft PR out for this (https://github.com/openjdk/jdk/pull/5909), and a branch that contains a quickly merged repo (https://github.com/openjdk/jdk/compare/master...tschatzl:submit/virtualize-g1card-config-card-set-size?expand=1).
Are there any problems with waiting a bit for this change on PR#5909?

Maybe you are also interested to try out the combination of PR#5909 and this one, allowing card table entry sizes from 128 to 1024 and any combination of region size iirc.

In PR#5909 there is also the question of how large regions G1 should allow with that - the patch currently allows up to 512M regions, but theoretically there is no limit - do you have any opinion on that?

Thanks,
  Thomas

src/hotspot/share/gc/parallel/objectStartArray.hpp line 60:

> 58: 
> 59:   // This maximum is derived from that we need an extra bit for possible
> 60:   // offsets in the byte for backskip values (this is a hard limit)

Suggestion:

  // Maximum size an offset table entry can cover. This maximum is derived from that we need an extra bit for possible
  // offsets in the byte for backskip values, leaving 2^7 possible offsets. Mininum object alignment is 8 bytes (2^3), so we can at most represent 2^10 offsets within a BOT value.


(We *could* make this maximum dependent on `ObjectAlignmentInBytes`, but I do not know if increasing ObjectAlignmentInBytes gives any advantage. So at most defer this investigation to some other time as I'm already keeping busy some machines)

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

PR: https://git.openjdk.java.net/jdk/pull/5838