JDK-7044738 : Loop unroll optimization causes incorrect result
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21,6u26-rev,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris
  • CPU: generic
  • Submitted: 2011-05-13
  • Updated: 2013-04-24
  • Resolved: 2011-09-30
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 6 JDK 7 JDK 8 Other
6u29Fixed 7Fixed 8Fixed hs20.3Fixed
Related Reports
Relates :  
JDK-6384206 - Phis which are later unneeded are impairing our ability to inline based on static types
Description
Test testAssignSameArrayInstance produces incorrect result when loop is unrolled. The test passes with -XX:LoopUnrollLimit=1.

$ unzip -w MicroBenchmarks2.zip
% /java/re/jdk/7/latest/binaries/solaris-i586/bin/java -jar MicroBenchmarks/target/microbenchmarks.jar '.*JGAssign.*SameArrayInstance'
CompilerOracle: print oracle/micro/benchmarks/api/java/lang/StringMicros.compareTo
Java HotSpot(TM) Server VM warning: printing of assembly code is enabled; turning on DebugNonSafepoints to gain additional output
# Starting run at: Fri May 13 11:34:18 PDT 2011
# Runtime (per iteration): 10s
# Iterations: 5
# Thread counts (concurrent threads per iteration): [1, 1, 1, 1, 1]
# Running: oracle.micro.benchmarks.app.javagrande.section1.JGAssign.testAssignSameArrayInstance
May 13, 2011 11:34:18 AM oracle.micro.api.runner.MicroBenchmarkHandler runIteration
SEVERE: java.lang.reflect.InvocationTargetException
java.util.concurrent.ExecutionException: java.lang.reflect.InvocationTargetException
	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
	at java.util.concurrent.FutureTask.get(FutureTask.java:111)
	at oracle.micro.api.runner.MicroBenchmarkHandler.runIteration(MicroBenchmarkHandler.java:266)
	at oracle.micro.api.runner.MicroBenchmarkHandler.runIteration(MicroBenchmarkHandler.java:235)
	at oracle.micro.api.runner.Runner.runMicroBenchmark(Runner.java:249)
	at oracle.micro.api.runner.Runner.run(Runner.java:87)
	at oracle.micro.Main.main(Main.java:35)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at oracle.micro.api.runner.MicroBenchmarkHandler.runBenchmark(MicroBenchmarkHandler.java:290)
	at oracle.micro.api.runner.MicroBenchmarkHandler.access$100(MicroBenchmarkHandler.java:44)
	at oracle.micro.api.runner.MicroBenchmarkHandler$BenchmarkTask.call(MicroBenchmarkHandler.java:642)
	at oracle.micro.api.runner.MicroBenchmarkHandler$BenchmarkTask.call(MicroBenchmarkHandler.java:600)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: Something went very wrong
	at oracle.micro.benchmarks.app.javagrande.section1.JGAssign.testAssignSameArrayInstance(JGAssign.java:270)


% /java/re/jdk/7/latest/binaries/solaris-i586/bin/java -server -XX:LoopUnrollLimit=1 -jar MicroBenchmarks2/target/microbenchmarks.jar '.*JGAssign.*SameArrayInstance'
CompilerOracle: print oracle/micro/benchmarks/api/java/lang/StringMicros.compareTo
Java HotSpot(TM) Server VM warning: printing of assembly code is enabled; turning on DebugNonSafepoints to gain additional output
# Starting run at: Fri May 13 11:38:06 PDT 2011
# Runtime (per iteration): 10s
# Iterations: 5
# Thread counts (concurrent threads per iteration): [1, 1, 1, 1, 1]
# Running: oracle.micro.benchmarks.app.javagrande.section1.JGAssign.testAssignSameArrayInstance
Iteration 0 : 2215977.19 ops/msec (1 thread)
Iteration 1 : 2316648.941 ops/msec (1 thread)
Iteration 2 : 2112895.379 ops/msec (1 thread)
Iteration 3 : 2320857.038 ops/msec (1 thread)
Iteration 4 : 2320931.319 ops/msec (1 thread)

Run result: 2257461.974 ? 102647.210
Run statistics: min = 2112895.379, avg = 2257461.974, max = 2320931.319, stdev = 82669.071, confidence interval (alpha=0.05) = [2154814.764, 2360109.183]
Estimated amount of iterations needed for an error of 5.00%: 17
Comments
EVALUATION See main CR
12-09-2011
EVALUATION See main CR
01-09-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3cbc9ddd434
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3cbc9ddd434
07-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3cbc9ddd434
01-07-2011
EVALUATION It is rare case when OSR compilation is done for nested loop which prevents ciTypeFlow to clone loop's head. As result the control node of loop's nodes is loop's back control. During loop iterations split clone_up_backedge_goo() creates clones for nodes which are pinned to loop's back control and it does not take into account memory dependencies by creating duplicated clones.
24-06-2011