JDK-8220714 : C2 Compilation failure when accessing off-heap memory using Unsafe
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version:
    8,8-shenandoah,11,11-shenandoah,12,13 8,8-shenandoah,11,11-shenandoah,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-03-15
  • Updated: 2019-08-15
  • Resolved: 2019-03-21
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 JDK 12 JDK 13
11.0.4Fixed 12.0.2Fixed 13 b14Fixed
Related Reports
Relates :  
JDK-8162101 - C2: Handle "wide" aliases for unsafe accesses
Description
A user reported misbehaving off-heap access. It looks like a C2 compilation failure that seems to only trigger with Shenandoah:

https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-March/009060.html

Eg with G1 generates this assembly for swapping two array elements:
mov    (%r8),%r9d
mov    (%r10),%r11d 
mov    %r9d,(%r10)
mov    %r11d,(%r8)

While with Shenandoah we get this:
mov    (%r9),%ecx         
mov    %ecx,(%r10,%r11,1) 
mov    %ecx,(%r9)      

I.e. the two loads seem to have been wrongly coalesced into one.

Even though that is only triggered by Shenandoah, it seems to be a legit and generic C2 problem.
Comments
This seems to be equivalent fix for 8: diff -r 340c26a13acf src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Fri Mar 15 09:57:42 2019 +0100 +++ b/src/share/vm/opto/library_call.cpp Tue Apr 30 18:14:11 2019 +0200 @@ -2736,7 +2736,7 @@ // the barriers get omitted and the unsafe reference begins to "pollute" // the alias analysis of the rest of the graph, either Compile::can_alias // or Compile::must_alias will throw a diagnostic assert.) - bool need_mem_bar = (alias_type->adr_type() == TypeOopPtr::BOTTOM); + bool need_mem_bar = (alias_type->adr_type() == TypeOopPtr::BOTTOM) || is_native_ptr; // If we are reading the value of the referent field of a Reference // object (either by using Unsafe directly or through reflection)
30-04-2019
It seems mainline 8u touched a lot of code around it, notably with JDK-8221355 and before that: the affected line was dropped, because the code shape got changed as part of that fix. Nevertheless, the test still fails even with current 8u212. Shenandoah test backported to 8u: http://cr.openjdk.java.net/~shade/8220714/test-shenandoah-8u.patch. This means we have to come up with some other fix for 8u.
30-04-2019
Fix Request (12u, 11u) Backporting this fix resolves a bad miscompilation that can manifest with Unsafe code. It is not critical for 11.0.3, because we have only seen it once with Shenandoah. The patch applies to 11u and 12u without problems, passes the new regression test (and fails the test without the fix). x86_64 passes tier1 in both 11u and 12u with the patch.
01-04-2019
Patch includes Shenandoah-specific test, adding 8-shenandoah and 11-shenandoah to backport it separately.
01-04-2019
It seems to have been introduced by JDK-8162101.
15-03-2019