RFR: 8272773: Investigate making card table size configurable

[Thomas Schatzl]

On Fri, 8 Oct 2021 11:02:56 GMT, Vishal Chand <github.com+10235864+vish-chan at openjdk.org> wrote:

>> That same question will come up if we allow 64m regions later, but the step from 64->32m may not be that big. Another option would be to go away from the 1:1 mapping of cards in the remembered set and cards in the card table. This could probably be fixed, but is a completely different issue of course.
>
> In this current implementation, with G1 GC, `card_size` is initialized after determining the `region_size` inside `setup_heap_region_size()`. `card_size` value is determined as `MAX(GCCardSizeInByte, minimum card size for the region size)`. So, if user selects `GCCardSizeInBytes=256` and G1 ergonomically decides to use 32M regions, `card_size` is silently set to 512b.  And, if user selects `GCCardSizeInBytes=1024` and G1 ergonomically decides to use 32M regions, `card_size` stays at 1024b. In case user doesn't specify any card_size, default value of 512b is used. We can set it ergonomically, but thats a completely new problem. 
> With Parallel and Serial GC, we directly use `GCCardSizeInBytes`, as there's no dependency.

I understand the code, but the problems are elsewhere:
* this restriction is G1 only, but the code handling this situation is in common code (in the common `cardTable.cpp`, not in e.g. `g1CardTable*`). I do not have an extremely strong opinion about this at the moment.
* the code overrides a user decision _silently_, which is not a good idea imho. The typical solution is that other settings that the user did not explicitly specified try to adapt to these. However in this case, doing that would be in almost all cases disadvantageous (I guess). Let's see what other people think about this.

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

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