JDK-8189276 : Make SuspendibleThreadSet and related code available to other GCs
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-10-13
  • Updated: 2017-11-10
  • Resolved: 2017-10-18
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 10
10 b31Fixed
Related Reports
Relates :  
JDK-8163329 - JEP 304: Garbage Collector Interface
Relates :  
JDK-8152199 - Restructure SuspendibleThreadSet::synchronize
Description
SuspendibleThreadSet is used in G1 to allow GC threads to participate in safepointing. It seems very useful for other GCs too and should be made available in a shared source directory.
Comments
Ah sorry, I only now understood that JDK-8188919 is the one that Erik ��. is currently working on. I can also add the generic STS hooks under this RFE, if you don't object? I.e. 1. move STS to runtime/ *and* also add the hooks and make G1 use those. I'll take another shot at CMS safepoint de/sync too.
14-10-2017
[~rkennke] That plan sounds fine, although I think a different RFE from JDK-8188919 will be needed for generalization of the STS hooks away from the heap object, unless you are planning to redirect that RFE. I mostly want to avoid moving STS first to gc/shared and then later to runtime/. And I agree that changing CMS to use STS is unfortunately not trivial. And might never happen, since CMS has been deprecated and doesn't seem to be receiving a lot of attention.
14-10-2017
Right. This goes a little out of scope for this issue though. I propose to move the STS code to runtime/ under this ID, then add the general STS hooks to safepoint.cpp under JDK-8188919 (thereby making G1 use that, and keep the heap 'API' for CMS only), and file a new issue to make CMS use STS (I tried that before... this is far from trivial), at which point we can ditch the heap suspend/resume API again. Sounds good?
14-10-2017
ParallelGC doesn't need this; it doesn't have threads running concurrently with the mutator that need to be stopped for a safepoint. I think CMS ought to be changed to use STS rather than it's own thing.
13-10-2017
I believe this should be possible. The API can be made available anywhere, e.g. in SafepointSynchronize or directly in STS (in addition to the heap API, which also supports CMS and ParallelGC which are not (yet) using the STS mechanism).
13-10-2017
Should it be made more general even than just available to other GCs? It seems like there are other (possible) threads that might want some similar mechanism. That is, maybe this facility belongs in runtime rather than in (say) gc/shared. Though if we're going to do that, probably the API should be somewhere other than on the heap, as is being done by JDK-8188919.
13-10-2017