JDK-7044738 : Loop unroll optimization causes incorrect result
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: hotspot
  • Sub-Component: compiler
  • Priority: P3
  • Affected Version: hs21,6u26-rev,7
  • OS: generic,solaris
  • CPU: generic
  • Submit Date: 2011-05-13
  • Updated Date: 2013-04-24
  • Resolved Date: 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 Availabitlity Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u29Fixed 7Resolved 8Resolved
Related Reports
Relates :  
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
2011-09-12

EVALUATION See main CR
2011-09-01

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3cbc9ddd434
2011-07-08

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3cbc9ddd434
2011-07-07

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3cbc9ddd434
2011-07-01

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.
2011-06-24