Bug ID: JDK-8073866 Fix for 8064703 is not sufficient

Type: Bug
Component: hotspot
Sub-Component: compiler

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2015-02-25
Updated: 2023-01-06
Resolved: 2015-03-20

Versions (Unresolved/Resolved/Fixed)

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 9
9 b64Fixed

That fix makes deoptimization in arraycopy restart execution at the tightly coupled allocation. It is not robust enough. It leaves an uninitialized unreferenced array in the heap. That could break with CMS (see JDK-8073796). As pointed by GC folks, VerifyGC or anything that walks the entire heap could break as well. So we need to either disable the optimization that looks for tightly coupled allocations with CMS + VerifyGC etc. or find another way to fix the problem (do the zeroing right before the uncommon trap? In the deoptimization code? Move the guards before the allocation?)

URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5bc4954b575c User: lana Date: 2015-05-13 21:19:48 +0000
13-05-2015
URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/5bc4954b575c User: roland Date: 2015-03-20 20:29:37 +0000
20-03-2015
Fix for 8064703 may also cause stores between the allocation and arraycopy to be rexecuted after a deoptimization and so lead to incorrect execution.
09-03-2015
ILW=H(could crash) L(never seen) M(disable arraycopy intrinsics)=P3
25-02-2015

Relates :	JDK-8064703 - crash running specjvm98's javac following 8060252
Relates :	JDK-8297730 - C2: Arraycopy intrinsic throws incorrect exception
Relates :	JDK-8075921 - assert assert(allocx == alloc) fails in library_call.cpp