RFR: 8272773: Investigate making card table size configurable

[Vishal Chand]

On Fri, 8 Oct 2021 10:39:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Let's leave this question out for now: I am not sure it makes sense to allow a card size of 256; however the common reaction when specifying incompatible command line options would be to bail out.
>> The question is what to do if the user selects GCCardSizeInBytes=256 and G1 ergonomically decides to use 32m regions. Silently use 16m regions, which are very likely worse than 32m regions in that case?
>> That is why we should first determine if card size of 256 makes sense somewhere and then decide (or somebody else has a particular opinion on this).
>
> 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.

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

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