-
Enhancement
-
Resolution: Unresolved
-
P4
-
20
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
"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