JDK-8238861 : Remove suspend_flag
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-02-11
  • Updated: 2022-03-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.
Other
tbdUnresolved
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Removing _suspend_flag and has_special_runtime_exit_condition/handle_special_runtime_exit_condition and friends will greatly simplify transition and will make it possible to contain the functionality.
Right now it's spread out all over the runtime and we have many special transition for not getting this wrong.
Delivery conditions are duplicate and very hard to understand.

The _suspend_flag is asynchronous and target executed:
Set bit X and thread execute method Y when doing a transition where the delivery terms are met.

Since we already have a safepoint(/handshake) poll at every possible delivery location, these can be implementerad as handshake (if we had the correct functionality).
The handshake operation could contain both the delivery terms and the delivery, thus having everything at one place and only once.

There are now 4 (soon 5) users:
  - Suspend/resume
  - Delivering Asynchronous exception (ThreadDeath)
  - Lazy JNI critical unlocking
  - JFR Native trace blocking
  - Local variable reconstitution