JDK-8209974 : Eliminate shared PtrQueues
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2018-08-26
  • Updated: 2019-03-26
  • Resolved: 2019-03-22
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
tbdResolved
Related Reports
Blocks :  
JDK-8209975 - Some GCThreadLocalData not initialized
Blocks :  
JDK-8219613 - Use NonJavaThread PtrQueues
Blocks :  
JDK-8210024 - JFR calls virtual is_Java_thread from ~Thread()
Relates :  
JDK-8162929 - Enqueuing dirty cards into a single DCQS during GC does not scale
Relates :  
JDK-8170020 - Add helper for shared PtrQueue enqueuing
Relates :  
JDK-8220240 - Refactor shared dirty card queue
Relates :  
JDK-8215097 - Do not create NonJavaThreads before BarrierSet
Relates :  
JDK-8173211 - G1: Enqueuing dirty cards during reference enqueuing in phase 3 does not scale
Description
Each SATBMarkQueueSet and DirtyCardQueueSet has a shared queue of the corresponding type.  These shared queues are used by enqueue operations when the current thread is not a JavaThread.  However, even non-JavaThreads have embedded GCThreadLocalData, which contains the per-thread SATB and dirty card queues.  We should just use those queues, rather than a (possibly highly contended) shared queue.
Comments
No longer an issue. Addressing the various related and blocking issues (in particular JDK-8219613 and JDK-8220240) has dealt with this.
22-03-2019