JDK-8181822 : C2: Mixed unsafe oop accesses break alias analysis
  • Type: Backport
  • Backport of: JDK-8155635
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-06-08
  • Updated: 2019-03-23
  • Resolved: 2018-10-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.
8u202 b02Fixed 9Fixed
I attached a microbenchmark showing the difference. On 8u192, 9 and 11 the loop runs in about 40ms but with 8u202 it takes about 3000ms.

Why is the version of this fix for 8 different than what's in 9 and later? This piece of it // Can base be NULL? Otherwise, always on-heap access. bool can_access_non_heap = TypePtr::NULL_PTR->higher_equal(_gvn.type(heap_base_oop)); + if (can_access_non_heap && type == T_OBJECT) { + return false; // off-heap oop accesses are not supported + } means that if the base pointer hasn't been null checked before the Unsafe.getObject then it won't be intrinsified at all. 9 and later don't have this check. http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/b756e7a2ec33/src/share/vm/opto/library_call.cpp#l2324 We see a huge slowdown in some code using Unsafe for reflection as a result of this change.

Test test/compiler/unsafe/MixedUnsafeStoreObject.java passed on linux x64

The priority of the main bug was increased to P1 when the issue started to appear in JPRT. This is not the case for 8 so this backport is not a P1.

Added 8 since I don't know if it this issue is regression of any 8 update.