JDK-8215220 : Simplify Shenandoah task termination in aborted paths
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-11
  • Updated: 2019-05-16
  • Resolved: 2018-12-13
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 JDK 13
12 b24Fixed 13Fixed
Related Reports
Blocks :  
JDK-8215047 - Task terminators do not complete termination in consistent state
Description
During upstreaming ShenandoahTaskTermination and investigating inconsistent termination state reported by Thomas Schatzl, I believe we don't have to offer termination from every worker threads, since task termination should reach consistent state at then end, regardless it is normal or aborted termination (see JDK-8215047 for details).

That says, Shenandoah can dramatically simplify task termination logic, and eliminates ShenandoahCancelledTerminatorTerminator.

This work does not depend on fixing of JDK-8215047, because it does not reuse terminator.
Comments
Imho it is easier to reason about the correctness of the use if all threads simply call the method at some point when looking at the code. Of course there are overriding concerns like readability of code of course; but it does not seem that there is a significant performance disadvantage here. It has been a recommendation by me only too, so we can agree to disagree :) Also I understand that whatever is fixed in JDK-8215047 for OWST will also be changed with the ParallelTaskTerminator - simply for the reason that they should behave the same. But that is a different discussion to be held elsewhere.
11-12-2018
[~tschatzl I don't think it is an violation, because one of termination conditions, is _offered_termination == 0 (for aborted termination). Forcing a worker to enter termination protocol (++offered_termination), then just leave (--_offered_termination) due to aborted condition, does not accomplish anything. In fact, if we have JDK-8215047 fixed, this scenario will always result _offered_termination == 0 (I tested with my OWST only fixes for JDK-8215047). Without JDK-8215047 fixes, forcing workers to enter termination protocol in aborted scenario, actually increases the chances of terminating in inconsistent states.
11-12-2018
Imho: I do not recommend intentionally violating the expectations of the task termination - one interesting assert would exactly be checking whether all tasks terminated at the end of that operation.
11-12-2018