JDK-8155781 : C2: opaque unsafe access triggers an assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-04-30
  • Updated: 2017-11-29
  • Resolved: 2016-07-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.
8u152Fixed 9 b129Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
The following code hits an assert during compilation:   
    static int test(Object o) {
        return UNSAFE.getInt(o, F_OFFSET);

#  Internal Error (/Users/vlivanov/ws/jdk/hs-comp9/hotspot/src/share/vm/opto/library_call.cpp:2426), pid=12063, tid=23043
#  assert(alias_type->adr_type() == TypeRawPtr::BOTTOM || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->basic_type() != T_ILLEGAL) failed: field, array element or unknown

I spoke with Vladimir about this, given that this is affecting the macosx fastdebug builds, he will be pushing the fix for this to jdk9/dev tomorrow after running some pre integration testing.

I'm getting the following on OS X. It may be (hopefully) related.

This is creating intermittent build failures for fastdebug macosx, both on Mach 5 and JPRT. We've seen the error in 2 Mach5 builds and I got on a JPRT job failure that later built on rerun. We are debating if we should wait until this is fixed in jdk9/dev before taking a new snapshot for Master, so I'm going to increase the priority to 1. Please push the fix to jdk9/dev

Confirmed with a JPRT build of jdk9/dev. Looks like the j.u.c changes have exposed a VM bug in unsafe handling.

ILW = assert; Unsafe; none = MMH = P3