JDK-8224759 : Investigate block splitting during heap root scan
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-05-24
  • Updated: 2021-12-15
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-8213108 - Improve work distribution during remembered set scan
Relates :  
JDK-8278824 - Uneven work distribution when scanning heap roots in G1
Relates :  
JDK-6672778 - G1 should trim task queues more aggressively during evacuation pauses
Description
With JDK-8213108 consecutive dirty cards are scanned as a single block. This may result in pushing a lot of references to scan into the task queue (64kb chunk size, ie. 16k references max).

During development of JDK-6672778 we found that having less references on the task queue is advantagous due to memory prefetching/caching reasons.

Investigate the impact of splitting blocks on a smaller granularity than chunk size.

BigRAMTester and SPECjbb2015 have a few GCs (at the start iirc) where the block/chunk size is very small, i.e. G1 can find many large blocks.

Very short attempts on e.g. limiting block size to 4 cards (random number) showed no conclusive initial advantage or disadvantage in pause times.
Comments
There is another reason why it is advantageous to have less elements on the task queue - stealing can be expensive.
15-12-2021