-
Bug
-
Resolution: Fixed
-
P2
-
11, 16, 17
-
b14
-
b14
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8267868 | 15.0.4 | Sergey Nazarkin | P2 | Resolved | Fixed | b03 |
JDK-8271394 | 13.0.9 | Sergey Nazarkin | P2 | Resolved | Fixed | b01 |
JDK-8264430 | 11.0.12-oracle | Dukebot | P2 | Closed | Fixed | b01 |
JDK-8265344 | 11.0.12 | Nils Eliasson | P2 | Resolved | Fixed | b01 |
make test JTREG="VERBOSE=all;JAVA_OPTIONS=-XX:-UseCompressedOops -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=0 -Xmn1m -XX:G1HeapRegionSize=1m -Xmx10m -Xlog:gc -XX:-ReduceInitialCardMarks" TEST=compiler/arraycopy/TestEliminateArrayCopy.java
The following crash report is generated rather deterministically:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/compressedOops.inline.hpp:81
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/scratch/eosterlu/oracle/jdk/jdk-jdk.git/open/src/hotspot/share/oops/compressedOops.inline.hpp:81), pid=15191, tid=15213
# assert(Universe::is_in_heap(v)) failed: object not in heap 0xbaadbabebaadbabe
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (slowdebug build 17-internal+0-LTS-2021-02-22-0951114.eosterlu...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 17-internal+0-LTS-2021-02-22-0951114.eosterlu..., mixed mode, sharing, tiered, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x58664b] CompressedOops::decode_not_null(oopDesc*)+0x29
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /scratch/eosterlu/oracle/jdk/jdk-jdk.git/build/slowdebug/test-support/jtreg_open_test_hotspot_jtreg
_compiler_arraycopy_TestEliminateArrayCopy_java/scratch/0/core.15191)
#
# An error report file with more information is saved as:
# /scratch/eosterlu/oracle/jdk/jdk-jdk.git/build/slowdebug/test-support/jtreg_open_test_hotspot_jtreg_compiler_arraycopy_TestEliminateArrayCopy_java/scratch/0/hs_err_pid15191.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
#
The problem seemingly occurs when cloning an object array. The operation entails allocating a new array, and copying the source array contents into the destination array.
In the path that fails, array_copy_requires_gc_barriers() returns false when ReduceInitialCardMarks is true. This will perform a raw copy, which is fine. However, when ReduceInitialCardMarks is false, we enter a code path where we have to select the right arraycopy stub. In particular, we have to calculate correctly if the destination is uninitialized. Something goes wrong here, and the compiler picks the arraycopy stub that assumes the destination is initialized, while in fact it is not. That causes G1 to fail rather deterministically.
It might however be a problem for SATB collectors in general, that the incorrect annotation of whether the destination is initialized or not, causes reading of uninitialized memory in GC barriers.
- backported by
-
JDK-8265344 Incorrect arraycopy stub selected by C2 for SATB collectors
- Resolved
-
JDK-8267868 Incorrect arraycopy stub selected by C2 for SATB collectors
- Resolved
-
JDK-8271394 Incorrect arraycopy stub selected by C2 for SATB collectors
- Resolved
-
JDK-8264430 Incorrect arraycopy stub selected by C2 for SATB collectors
- Closed
- relates to
-
JDK-8263615 Cleanup tightly_coupled_allocation
- Resolved
- links to
-
Commit openjdk/jdk13u-dev/4d40fee7
-
Commit openjdk/jdk15u-dev/ebaf7e16
-
Commit openjdk/jdk/5d87a219
-
Review openjdk/jdk13u-dev/238
-
Review openjdk/jdk15u-dev/52
-
Review openjdk/jdk/3008