JDK-6507028 : _suspend_flags are not atomically updated in all cases
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic,sparc
  • Submitted: 2006-12-21
  • Updated: 2012-10-08
  • Resolved: 2007-01-17
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 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Duplicate :  
Relates :  
Description
The recent fix for 6463133 (deopt should not use code patching) uses one bit of the _suspend_flags to indicate that deopt is necessary. However no concurrency controls are applied to the update of _suspend_flags, and so changes might be lost if multiple bits are modified concurrently.

In the past the _suspend_flags contained a number of VM/Java-suspend related flags, and the async-exception flag was also stored there. Hence updates to the _suspend_flags were protected by acquiring the SR_lock (suspend/resume lock). With the demise of VM suspension, and the additional use of the "deopt" bit, these flags are now more general purpose "condition" flags and protecting updates with the SR_lock is no longer appropriate. Instead the _suspend_flags should be updated atomically using a compare-and-swap operation.

Comments
SUGGESTED FIX Use a CAS loop to update the _suspend_flags atomically.
21-12-2006

EVALUATION See description.
21-12-2006