Bug ID: JDK-8296803 Reconsider grow hint defaults for G1 card set hash table

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

From hotspot-gc-dev:

"Currently G1CardSet uses a concurrent hash table under the hood to keep a mapping between heap regions and card set containers. After running some experiments, I found adjusting the grow hint of the underlying concurrent hash table can potentially bring down the overall CPU usage of the process quite a bit.

Here is a brief summary of my testing result:

Benchmark: BigRamTester

JDK version: master branch, commit 779b4e1d1959bc15a27492b7e2b951678e39cca8

Testing command: java -XX:+AlwaysPreTouch -Xlog:gc*=debug:gc.log::filecount=10,filesize=20m -Xms20g -Xmx20g BigRamTester

Without any modification, the average CPU usage (measured by top, with 5-min sampling period) is roughly 660%; After changing the grow hint of the card set concurrent hash table from 4 to 1, the CPU usage can be reduced to 620%.

The impact of this change on memory usage is minimal. The RES (report by top) before/after the change is something like 21.295G vs 21.30G, and the native memory usage of G1CardSet (report by NMT) also shows no difference.

Theoretically by increasing the grow hint, we are preferring a more "flatten" hash table: less time is spent on traversing the collision list, less CPU is used. What I propose is, shall we make the grow hint a configurable parameter? Please let me know if i missed anything. "

from https://mail.openjdk.org/pipermail/hotspot-gc-dev/2022-June/039578.html

Initial response: " we've had something like this in the initial implementation but did not have time to look into this some more, so removed that interface to the user. E.g. see the constructor of G1CardSetHashTable where there is a parameter to set its initial size, but never use it. Same about the maximum typical number of links in the chain. Similar applies to G1SegmentedArrayAllocOptions always being the same (or even having different G1CardSetConfigurations). Did you test with different initial settings for different types of regions? Particularly bigramtester tends to have fairly unique distribution depending on generation iirc. Ideally these values would somehow be automatically derived, and not set by an option. So in general, yes, we are interested in improvements there. As a first step it would also be useful to e.g. print gc/refinement threads' vtime (I think this would mostly reduce refinement thread vtimes?) in a more straightforward/useful manner (and just ignore the OSes where this is not easily possible). I'm thinking about some (periodic?) log output that just prints (refinement) thread vtimes one after another (maybe relative?), maybe with an initial header, but I haven't thought it through. There is some (badly formatted) output for the marking threads iirc already. At least I think it would generally be fairly useful to provide such information by the VM as hooking some third party tool is sometimes a bit cumbersome."

10-11-2022