JDK-8204947 : Port ShenandoahTaskTerminator to mainline and make it default
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-06-13
  • Updated: 2020-02-28
  • Resolved: 2018-12-07
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 12
12 b24Fixed
Related Reports
CSR :  
JDK-8214458 - Port ShenandoahTaskTerminator to mainline and make it default
Relates :  
JDK-8215047 - Task terminators do not complete termination in consistent state
Relates :  
JDK-8218975 - Bug in macOSX kernel's pthread support
Relates :  
JDK-8240216 - Shenandoah: remove ShenandoahTerminationTrace
Relates :  
JDK-8238162 - Shenandoah: Remove ShenandoahTaskTerminator wrapper
Relates :  
JDK-8215297 - Remove ParallelTaskTerminator
Description
The ShenandoahTaskTerminator from the Shenandoah project is a much better implementation of a task terminator.

Port it to mainline and make it default; optionally allow switching to the old one for one release.
Comments
This is useful to have for upstreaming Shenandoah, otherwise we'd have to upstream some API changes in taskqueue.hpp
28-11-2018
Given CMS is depreciated, should this RFE still need to address CMS? cause CMS likely gone when this feature comes out of experimental flag.
27-11-2018
Okay, then. I thought this approach is a bit invasive, given we are going to have selection flag only for one release cycle.
27-11-2018
Some classes (G1ConcurrentMark, ConcurrentMarkSweepGeneration) are indeed allocating terminators as embedded members. I think the best solution would be to change these to be pointers and heap allocate them (changing the allocation base class for ParallelTaskTerminator). That's assuming we want to be able to conditionally select between the old and the new behavior by selecting different classes, rather than having the conditionalization in the implementation of the single terminator class. (CMS has a specialized terminator derived from ParallelTaskTerminator, which might require additional work.) I don't think unions (unrestricted or otherwise) are a useful technique here. I don't think there's any reason to wait for C++14 support here.
26-11-2018
It turns out, the port can be very invasive for current GCs. There are many instances that ParallelTaskTerminator is used as Value object, vs. Stack object as it is declared. I tend to postpone this RFE till we have C++14. Unrestricted union (is it permitted?) seems can do the trick to minimize the port. Any suggestions?
17-10-2018