JDK-8162826 : Missing load-acquire in relation to methodData code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-08-01
  • Updated: 2022-05-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.
Other
tbdUnresolved
Related Reports
Relates :  
Description
In ./share/vm/oops/methodData.hpp: we have:

OrderAccess::release_store_ptr(&_cells[index], value);

with no sign of any corresponding load-acquire. This usage is highly  suspect. The methodData code has a lot of potential paths to release_store_ptr, and in some places simple release(), combined with some locking. There are no load-acquire uses, in fact there are a couple of comments:

    // No need for "OrderAccess::load_acquire" ops,
    // since the data structure is monotonic.

I do not know what that is intended to mean.

As far as I can see, despite a variety of release_set_xxx methods in the API the only active use is of release_set_bci in RetData::fixup _ret which has the comment:

      // Barrier to ensure displacement is written before the bci; allows
      // the interpreter to read displacement without fear of race condition.

which means that somewhere in the interpreter code there should be a read of a BCI preceding a read of  displacement. That read of BCI should be a load-acquire to pair with the use of release_set_bci.