JDK-8186839 : Memory ordering of _state in nmethod is not clear
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10,11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2017-08-28
  • Updated: 2019-01-15
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
Relates :  
JDK-8186837 - Memory ordering nmethod, _state and _stack_traversal_mark
Description
The memory ordering demands of concurrent writing/reading of _state and another members of nmethod is unclear.
E.g. in aarch64 it's loaded via ldr and not lda, is this correct considering we have storestore fence between store of _stack_traversal_mark and _state?
Comments
IIRC 8020151 added a storestore but not matching loadload. Then 8180932 tried to fix that but got it wrong. So 8186837 then "fixed" that by rolling it back and just doing the basic loadload that was missing. But overall this still leaves things very unclear as to how _state and _stack_traversal_mark need to be ordered, other than on the two specific code paths already addressed. So really 8186839 needs to look at all uses of those fields and analyze their concurrency relations to see if additional ordering constraints are needed. No quick answers I'm afraid.
03-04-2018
The storestore fence was added by Albert with JDK-8020151 to ensure that before a method is set to not entrant, it must be marked as seen on the stack. Otherwise, instructions could be reordered and the sweeper thread could see a method that was just set to not entrant but has not yet been marked as seen on the stack. That method would then immediately transition to zombie which is incorrect. Now I'm not a memory ordering expert but since this was already discussed in the RFR for JDK-8186837, [~rehn], [~rkennke], [~dholmes], any new insights?
19-03-2018
ILW = Potential memory ordering problem, never showed up, no workaround = MLH = P4
22-02-2018