JDK-8029162 : G1: Shared SATB queue never enabled
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,9
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-11-26
  • Updated: 2014-07-29
  • Resolved: 2014-01-10
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 8 JDK 9
8u20Fixed 9 b03Fixed
Related Reports
Blocks :  
JDK-8029255 - G1: Reference processing should not enqueue references on the shared SATB queue
Blocks :  
JDK-8029075 - String deduplication in G1
Description
As part of implementing String deduplication for G1 (JDK-8029075) I discovered that the shared SATB queue is never enabled (ever). In the current G1 implementation this bug has no side effect (as far as I can tell) because we do not depend on that queue for anything. This queue is only used when non-Java threads overwrites a object reference while concurrent marking is running. We don't have any such threads at the moment (the VM thread and concurrent marking thread actually overwrites references during reference processing, but they do it as part of a prepend to a list, so the original reference becomes the next value so it's not detached from the list).

The fix is simple, the function SATBMarkQueueSet::set_active_all_threads() needs to call shared_satb_queue()->set_active().

Since this bug has no side effect it's currently not a problem. However, this needs to be fixed before JDK-8029075 can be completed.

Current ILW = LLL = P5
However, this bug is blocking JDK-8029075, which at some point will change it to ILW = HMH = P1
Comments
noreg-hard justification: No way to provoke this problem. The shared queue is meant to be used by internal VM threads doing assignments to object reference fields. The only thread currently doing this is the VM thread while processing discovered references. But as it turns out, in that particular case we do not want to execute the G1 pre-barriers anyway (this is where the shared queue would be used) because that would fail SATB queue verification. So, the fact that the shared queue was always disabled was in this case just a good thing.
05-12-2013