Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082624 | emb-9 | Roland Westrelin | P3 | Resolved | Fixed | team |
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?)
- backported by
-
JDK-8082624 Fix for 8064703 is not sufficient
- Resolved
- relates to
-
JDK-8064703 crash running specjvm98's javac following 8060252
- Closed
-
JDK-8075921 assert assert(allocx == alloc) fails in library_call.cpp
- Closed
-
JDK-8297730 C2: Arraycopy intrinsic throws incorrect exception
- Resolved