JDK-8267830 : G1: Investigate G1CardSet ConcurrentHashTable sizing heuristics
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 18
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2021-05-27
  • Updated: 2025-11-14
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
Related Reports
Blocks :  
JDK-8017163 - G1: Refactor remembered sets
Relates :  
JDK-8358342 - G1: G1CodeRootSet performance breaks down on even moderate load
Description
During clearing of the card set, we currently dump the associated ConcurrentHashTable and recreate it with InitialLogTableSize.

Investigate the benefit of having a ConcurrentHashTable sizing heuristic, that is keeping the tables at some specific other size to avoid constant resizing of these.

Initial attempts at doing so showed that this is a kind of waste of space, but more investigation should be done (particular e.g. limiting keeping some particular size to young gen regions; or size them to that "good" size only before adding elements, not keeping the ConcurrentHashTable around all the time etc).