JDK-8248226 : TestCloneAccessStressGCM fails with -XX:-ReduceBulkZeroing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,15,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-06-24
  • Updated: 2024-11-13
  • Resolved: 2020-07-07
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 11 JDK 16 JDK 8
11.0.10-oracleFixed 16 b05Fixed 8-poolUnresolved
Related Reports
Duplicate :  
JDK-8332388 - Incorrect results produced by OpenJDK 8 when set "-XX:-ReduceBulkZeroing" option
Relates :  
JDK-8235332 - TestInstanceCloneAsLoadsStores.java fails with -XX:+StressGCM
Description
java.lang.RuntimeException: Return value not 36. Got: 0; additional check:  36
	at compiler.arraycopy.TestCloneAccessStressGCM.main(TestCloneAccessStressGCM.java:58)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:832)
Comments
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.10-oracle. I had to resolve due to different context: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003764.html
03-09-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/ae002489df78 User: chagedorn Date: 2020-07-07 11:04:33 +0000
07-07-2020
http://cr.openjdk.java.net/~chagedorn/8248226/webrev.00/ C2 erroneously folds the addition in the return statement in the method TestCloneAccessStressGCM::test() to 0 when ReduceInitialCardMarks and ReduceBulkZeroing are disabled. The problem in the testcase can be traced back to LoadNode::find_previous_arraycopy() called from LoadNode::Ideal() for the loads dest.i1, dest.i2 etc. where we do not take GC barriers into account (disabled ReduceInitialCardMarks) when trying to find an ArrayCopyNode which belongs to a clone. As a result, we conclude that there is no ArrayCopyNode and bailout of the ideal transformation. Afterwards, we call LoadNode::Value() and look for a stored value for the allocation belonging to the clone() call. Since we cannot find one (because the ArrayCopyNode is initializing the allocation) we conclude that the field is 0 and replace the LoadNode by a constant 0. This happens for all the LoadNodes in the addition in the return statement which is then folded to 0 and returned. This could have been prevented if ReduceBulkZeroing was enabled. Because in that case, the InitializationNode would have been marked as completed at [1] and the InitializationNode::find_captured_store() method returned NULL at [2] and eventually the entire LoadNode::Value() method returned _type (int) instead of the constant 0 because of the bailout at [3] for completed InitializationNodes. [1] http://hg.openjdk.java.net/jdk/jdk/file/a7c030723240/src/hotspot/share/opto/library_call.cpp#l4234 [2] http://hg.openjdk.java.net/jdk/jdk/file/a7c030723240/src/hotspot/share/opto/memnode.cpp#l3775 [3] http://hg.openjdk.java.net/jdk/jdk/file/a7c030723240/src/hotspot/share/opto/memnode.cpp#l3722
03-07-2020
Seems to be the same issue.
02-07-2020
ILW = Incorrect result of compiled code, with debug stress option and single test, disable stress option = HLM = P3
24-06-2020
compiler/arraycopy/TestEliminateArrayCopy.java and compiler/arraycopy/TestInstanceCloneAsLoadsStores.java are also failing when being executed with "-XX:-ReduceInitialCardMarks -XX:-ReduceBulkZeroing". I suspect this to be the same issue. [~chagedorn], please file a new bug if that turns out not to be the case.
24-06-2020