JDK-8223162 : Improve ergonomics for Sparse PRT entry sizing
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-04-30
  • Updated: 2020-01-18
  • Resolved: 2019-06-03
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.
JDK 13 JDK 14
13 b24Fixed 14Fixed
Related Reports
Relates :  
JDK-8237500 - Increase the G1 eager reclaim candidate selection threshold
Sub Tasks
JDK-8225343 :  
Release Note: Improve Ergonomics for Sparse PRT Entry Size - Closed
Description
A few times already when people asked about excessive memory consumption for the remembered sets, the solution has been to increase the number of sparse prt entries per region significantly without impacting performance.

The current default of 4/8/12/16/20/24 entries (1-32MB regions respectively) is too small.
Comments
Final implementation chose dropping initial table size from 16 to 8 to preserve memory usage for applications that use very little remembered sets.
24-05-2019
Also, with higher usage of fine PRTs the risk is high to coarsen to Coarse PRTs, which are extremely slow to process during GC. More SparsePRTs will typically make GC faster, as scanning very sparsely populated bitmaps is comparatively slow.
15-05-2019
A simple fix that does not impact (relative) memory usage too much is to scale PRT entry number with region size too. Current memory usage / region = 16 (default# of SparsePRT for a region) * 2 (bytes per card entry) * 4 (G1RSetSparseRegionEntriesBase) * (log(region_size in MB) + 1) = 128-768 bytes -> 0.0122% (1M regions) to 0.00229% (32M regions) Suggested change: #entries = G1RSetSparseRegionEntriesBase * 2 ^ ((log(region_size in MB))) i.e. 8 - 128 entries, i.e. 256 - 4096 bytes for 16 PRTs -> 0.0244% of heap from 1M to 32M regions This significantly decreases usage of fine prts across many applications, which are still 256 bytes each minimum @ 1M region size (i.e. the extra cost of 128 bytes at that region size will be amortized by having a single fine PRT in one of the 16, i.e. a single region that references this region with more than 4 cards).
15-05-2019
One problem is that the entry size does not scale with region size: ie. region size scales exponentially, but sparse prt size only linearly. This means that with larger heaps there is a tendency to use fine prts, which means that they will use even more memory as they are both larger than sparse prt for more reasonable sizes and they also scale exponentially. This can significantly impact performance, as more memory usage means more memory to be processed during GC.
15-05-2019