JDK-8050972 : Concurrency problem in PcDesc cache
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u20,8u40,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-07-17
  • Updated: 2017-08-07
  • Resolved: 2014-07-22
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 8 JDK 9 Other
8u40Fixed 9 b26Fixed openjdk7uFixed
The entries of the PcDesc cache in nmethods are not declared as volatile, but they are accessed and modified by several threads concurrently.
Some compilers (namely xlC 12 on AIX) duplicate some memory accesses to non-volatile fields.
In this case, this has led to the situation that a thread had successfully matched a pc in the cache,
but returned the reloaded value which was already overwritten by another thread.

We consider this fix critical as it leads to severe errors in VMs built on AIX with xlC12.
For example jvm2008/sunflow does a wrong resolve and then throws an incompatible
class change error.  This happens about every second try to run this benchmark.

Since this bug doesn't occur on Oracle's platforms the release team has decided to not take it into 8u20 that late in the release cycle. We will backport to 8u40, though.