JDK-8211231 : BarrierSetC1::generate_referent_check() confuses register allocator
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-09-27
  • Updated: 2019-09-04
  • Resolved: 2018-10-02
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 11 Other
11.0.2Fixed openjdk8u212Fixed
We've seen this with Shenandoah but is not shenandoah specific:

The bug also exists in 8u. The code was in hotspot/src/share/vm/c1/c1_LIRGenerator.cpp before reshuffling. Added "Affects Versions: 8".

Please add a suitable noreg label.

Fix request This fixes the intermittent failures in code miscompiled by C1 when running with collectors that care about Reference.get loads (G1, Shenandoah, maybe ZGC). It is usually a dumb non-luck that register corruption does not lead to observable crashes. Patch applies semi-cleanly, because the non-patched line in the same block changed one argument from T_METADATA to T_OBJECT, compare these side by side: http://cr.openjdk.java.net/~shade/8211231/8211231-12.patch http://cr.openjdk.java.net/~shade/8211231/8211231-11u.patch

Test cases that involve register allocation are usually hard to write. So I don't think a test case is doable.

ILW = H(crash in compiled code) L(rare) M(disable compilation) = P3 Any possible regression test case!?