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
Description
We've seen this with Shenandoah but is not shenandoah specific:

http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-September/007605.html
Comments
The bug also exists in 8u. The code was in hotspot/src/share/vm/c1/c1_LIRGenerator.cpp before reshuffling. Added "Affects Versions: 8".
08-02-2019

Please add a suitable noreg label.
18-10-2018

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
17-10-2018

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

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