-
Bug
-
Resolution: Fixed
-
P2
-
8, 9, 10
-
b21
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8185714 | 9 | Tobias Hartmann | P2 | Closed | Won't Fix | |
JDK-8201672 | 8u192 | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
JDK-8188608 | 8u172 | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
JDK-8190595 | 8u171 | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
JDK-8184454 | 8u162 | Tobias Hartmann | P2 | Closed | Fixed | b01 |
JDK-8191215 | 8u152 | Tobias Hartmann | P2 | Closed | Fixed | b33 |
JDK-8198047 | emb-8u171 | Tobias Hartmann | P2 | Resolved | Fixed | b01 |
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
FULL OS VERSION :
- RHEL 7.3 Linux xxx.gs.com 3.10.0-514.16.1.el7.x86_64 #1 SMP Fri Mar 10 13:12:32 EST 2017 x86_64 x86_64 x86_64 GNU/Linux
- Ubuntu 17.10 with 4.12 kernel
- This is platform-agnostic
A DESCRIPTION OF THE PROBLEM :
C1 emits instructions in a sequence that violates program order when performing OSR + inlining code from the affected method.
This seems to be a subtle edge-case as referring the impacted value in checkResult() or using assert instead of "if" results in correct behavior.
Looking at the sequence of instructions emitted by C1 in this case (with PrintAssembly) clearly shows that C2 code produces valid instruction order whereas C1 does not.
Reducing inline level to 1 or disabling tiered compilation results in correct program behavior.
THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No
THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just run the following class with default java args.
It is also reproducible with manually inlined timeInvocation() + local variables inlined, but the provided example is clearer to work with.
EXPECTED VERSUS ACTUAL BEHAVIOR :
Should exit without printing anything.
Prints "should not get here ..." contrary to the expected behavior. Neither javac nor any of the JIT compilers should reorder capturing nanoTime value as there is a direct data dependency on the result of their subtraction.
The fact that System.nanoTime() return monotonic values guarantees result consistency.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class C1_OSR_Inline_Bug {
public static void main(String[] args) {
for (int i = 0; i < 100_000; i++) {
timeInvocation();
}
}
private static void timeInvocation() {
final long start = System.nanoTime();
final long end = System.nanoTime();
checkResult(end - start);
}
private static void checkResult(final long l) {
if (l < 0) {
System.out.println("should not get here " + l); // removing reference to l parameter here "fixes" the bug
System.exit(0);
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Reducing inline level to 1 or disabling tiered compilation result in correct program behavior.
The same applies to running in interpreted mode.
- backported by
-
JDK-8188608 Time related C1 intrinsics produce inconsistent results when floating around
-
- Resolved
-
-
JDK-8190595 Time related C1 intrinsics produce inconsistent results when floating around
-
- Resolved
-
-
JDK-8198047 Time related C1 intrinsics produce inconsistent results when floating around
-
- Resolved
-
-
JDK-8201672 Time related C1 intrinsics produce inconsistent results when floating around
-
- Resolved
-
-
JDK-8184454 Time related C1 intrinsics produce inconsistent results when floating around
-
- Closed
-
-
JDK-8185714 Time related C1 intrinsics produce inconsistent results when floating around
-
- Closed
-
-
JDK-8191215 Time related C1 intrinsics produce inconsistent results when floating around
-
- Closed
-
- duplicates
-
JDK-8267445 The time interval obtained with nanoTime in jdk9 is negative
-
- Closed
-
- relates to
-
JDK-8286263 compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3"
-
- Resolved
-
-
JDK-8267445 The time interval obtained with nanoTime in jdk9 is negative
-
- Closed
-