JDK-8137022 : Concurrent refinement thread adjustment and (de-)activation suboptimal
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-09-23
  • Updated: 2025-04-21
  • Resolved: 2022-10-20
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 20
20 b21Fixed
Related Reports
Blocks :  
JDK-8156696 - Simplify PtrQueueSet initialization
Blocks :  
JDK-8155996 - Improve concurrent refinement green zone control
CSR :  
JDK-8294206 - Concurrent refinement thread adjustment and (de-)activation suboptimal
Duplicate :  
JDK-8172918 - Investigate ways to push Update RS work into the concurrent phase
Relates :  
JDK-8293616 - Concurrent refinement by mutators only processes one buffer
Relates :  
JDK-8069330 - Adjustment of concurrent refinement thresholds does not take hot card cache into account
Relates :  
JDK-8139652 - Mutator refinement processing should take the oldest dirty card buffer
Relates :  
JDK-8133051 - Concurrent refinement threads may be activated and deactivated at random
Relates :  
JDK-8231153 - Improve concurrent refinement statistics
Sub Tasks
JDK-8295819 :  
Release Note: Improved Control of G1 Concurrent Refinement Threads - Resolved
Description
After every GC G1 readjusts concurrent refinement thresholds with the goal to have X amount of unprocessed buffers at the start of GC to process in the update RS phase. X is calculated from the time available for the Update RS phase.

The current calculation has the following issues:
- it allows the green threshold to get zero. This means that both refinement threads *and* mutators are competing for the buffers. There is no need to run the threads.
- there are magic factors to create the yellow and red thresholds that have nothing to do with actual application.
- (this may be another issue) activating more refinement threads is not in any way related to the rate they are added to the queue. Ideally more threads would be dynamically activated as the rate the buffers are added to the queue changes
Comments
[~kbarrett] Ok. I opened a new issue for this phenomenon. https://bugs.openjdk.org/browse/JDK-8355092
21-04-2025
[~tkiriyama] Please open a new issue for this. It's very easy to miss a comment in a long-ago closed issue.
17-04-2025
After JDK-8137022, some applications may experience longer processing times. This phenomenon occurs on 2-core Windows Server 2022 configuration, and not on a 4-core Windows Server 2022 or 2-core RHEL 9.4 configuration. Also, if '-XX: -G1UseConcRefinement' is specified, this problem does not occur. The application installs and starts around 300 OSGi bundles, then launches the Felix framework. ``` org.osgi.framework.launch.Framework framework; ... framework.getBundleContext().installBundle("xxx").start(); framework.start(); ``` As a result of my investigation, There's an increase in CPU time for G1 Refine threads compared to before the fix. environment: Windows Server 2022, 2 core x 2394 Mhz, 8GB memory - jdk17 (before the fix) processing time: 4286 ms CPU time for G1 Refine#0: 10.41 ms - jdk21 (after the fix) processing time: 6111 ms CPU time for G1 Refine#0: 1635.42 ms I don't find the same phenomenon in the following environments: Windows Server 2022, 4 core x 2600 Mhz, 8GB memory RHEL9.4, 2 core x 2.40 hHz, 8GB memory Will the JDK-8137022 fixes affect throughput performance?
17-04-2025
Changeset: 028e8b3d Author: Kim Barrett <kbarrett@openjdk.org> Date: 2022-10-20 20:29:19 +0000 URL: https://git.openjdk.org/jdk/commit/028e8b3d5e7e1791a9ed0af244f74d21fb12ba81
20-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10256 Date: 2022-09-14 00:36:18 +0000
14-09-2022
This issue from the original description: "- it does not take into account that there is always a set of (typically half-full) buffers attached to the threads at GC start." is really part of JDK-8155996. I'm moving it there.
12-09-2022
This issue from the original description: "- (this may be another issue) mutator-only processing only ever processes its own buffer. This is too little e.g. in case buffers are spilled over from mixed gc." has been moved to JDK-8293616.
10-09-2022
This issue from the original description: "- tries to improve the current (green) threshold by incrementally increasing/decreasing that threshold. The problem is that this multiplication factor basically does nothing at low thresholds" is really part of JDK-8155996. I'm moving it there.
10-09-2022
This item from the original description: "- (this may be another issue) it uses int's instead of size_t's for the thresholds" was fixed a long time ago.
10-09-2022
This item from the original description: "- (this may be another issue) the mutator processing takes the current buffer and processes it. In most cases this is just the wrong decision." was fixed a long time ago by JDK-8139652.
10-09-2022
Another point which may become obsolete with other changes: currently gc creates new refinement buffers for cards to scan to update the remembered sets concurrently. This may be a significant amount of buffers, so a lot of refinement threads are woken up after every gc to (often) essentially shut down immediately as the first few threads clean out that work faster than the threads can wake up. Leading to some kind of throughput issue right after a gc.
10-11-2017