JDK-8079167 : Fix documentation for G1SATBBufferEnqueueingThresholdPercent == 0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-04-30
  • Updated: 2024-06-03
  • Resolved: 2024-05-27
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 23
23 b25Fixed
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Description
SATBMarkQueue::should_enqueue_buffer calls filter() to eliminate entries that don't need to be marked, and returns true if the number of remaining entries is above the threshold specified by G1SATBBufferEnqueueingThresholdPercent.

The documentation for G1SATBBufferEnqueueingThresholdPercent says

  "A value of 0 specifies that mutator threads should not do such filtering."

There used to be a comment in should_enqueue_buffer that filtering was necessary even when that option was zero, to guarantee all entries in a completed buffer required marking.  However, with the relaxation of constraints on the content of completed SATB buffers in order to accomodate eager reclaim of humongous objects, that guarantee is no longer necessary or even met.

Because of that change of requirements, the filtering could now be skipped if G1SATBBufferEnqueueingThresholdPercent == 0, e.g. when enqueuing will always occur.

The benefit would be that instead of filtering out uninteresting elements in the mutator thread, it can be left to the filtering that is going to occur anyway in the CMTask thread.

The downside would be that the mutator thread queue is completed more often, and the transfer to the completed set has some overhead and may increase contention with other threads manipulating the completed set.

The intent of the documented behavior is presumably to permit that tradeoff to be made.  We should follow the documentation and enable that choice.

Update: [~kbarrett]'s comment below indicates that filtering is required, so the CR has been changed to just update the documentation, removing that remark about that a zero value should disable filtering.

Comments
Changeset: 61db2f5b Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2024-05-27 07:11:39 +0000 URL: https://git.openjdk.org/jdk/commit/61db2f5b90cd40ce104cb55bf9fd52d6e141161d
27-05-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/19385 Date: 2024-05-24 07:57:44 +0000
24-05-2024

There is another reason why filtering is required. Assume we've marked all live objects, but the concurrent marking termination protocol has not yet completed. One of the things that will prevent termination is the presence of enough completed buffers to exceed the threshold. In that situation, filtering prevents enqueuing completed buffers and allows marking to terminate.
18-06-2019

ILW = Low (behavior doesn't match documentation), Medium (for certain configurations), High (none) = P5
04-05-2015