JDK-8039147 : Cleanup SuspendibleThreadSet
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-04-03
  • Updated: 2015-01-21
  • Resolved: 2014-04-11
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.
8u40Fixed 9 b12Fixed
Related Reports
Relates :  
The SuspendibleThreadSet class currently lives in concurrentGCThread.hpp and has a somewhat strange relationship with ConcurrentGCThread. Even if the ConcurrentGCThread class, its sub-classes, are the main users of the SuspendibleThreadSet there are still other non-ConcurrentGCThread users (like by SharedHeap's FlexibleWorkGang returned by workers()).

ConcurrentGCThread owns the single instance of SuspendibleThreadSet and it's made accessible to its sub-classes via the _sts member. However, to allow other threads to use this all functions on the _sts instance are also exposed through a static API on the ConcurrentGCThread (the stsJoin(), stsLeave(), etc). So there are two APIs exposing for the same functions.

I suggest we break out and detach SuspendibleThreadSet from ConcurrentGCThread to make the APIs cleaner. I also suggest we add a "SuspendibleThreadSetJoiner" class (with similar semantics as a MutexLocker, with the difference that it joins/leaves the set), since the following pattern is fairly common:

if (....) {
   <do something>

which would the instead read:

if (....) {
   SuspendibleThreadSetJoiner sts;
   <do something>