-
Bug
-
Resolution: Fixed
-
P3
-
1.4.2_15, 5.0u8, 6
-
b56
-
x86, sparc
-
generic, solaris_9, windows_2000
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2149549 | 5.0u14 | Yumin Qi | P2 | Resolved | Fixed | b01 |
JDK-2149771 | 1.4-pool | Yumin Qi | P2 | Closed | Not an Issue | |
JDK-2168779 | 1.4.2_19 | Abhijit Saha | P3 | Resolved | Fixed | b02 |
JDK-2166320 | 1.4.2_18-rev | Walter Rockett | P3 | Resolved | Fixed | b11 |
Cliff Click of Azul Systems reports:
Hi! Long time no bug report - so I thought you might need one. :-)
This one happens with "java_g -server -Xmx512m -Xms512m -Xbatch
-XX:+PrintCompilation -XX:CompileOnly=foo.insert foo" and the included
foo.java, on 1.4.2_03 SparcV9 for sure (and +PrintOptoAssembly shows a
load scheduled before the null-check). I get funny OOM errors with the
product versions of later X86 & Sparc things; not sure if it's the same
crash.
Cliff
------------------------------------------------------------------------
From my putback msg:
The Ideal_DU_postCCP function removes CastPP's and replaces them with
control edges on memory ops. In order to give some scheduling freedom,
it tries to find a least restrictive control input that is also
sufficient to prevent hoisting above any needed null-check. In the case
of CountedLoops, it is willing to use a pre-loop control input. This is
not always correct: if the base value is known not-null but is a merge
at the loop head - at is null-checked on entry AND at the loop bottom -
then the old code would allow the control edge to move up to the
null-check on entry. The memory op could not float up out of the loop
because the base value merges at the loop head.
If we later unrolled the loop, the cloned memory op would then take
control from before the loop (like the original now does) and its base
input from the unrolled prior loop body - which has no merging phi and
whose CastPP was removed before unrolling. Hence the cloned memory op
could float above a needed null test.
Fix is to not lift the control above a CountedLoop, unless the base
value does not merge at the loop head (and is available already
null-checked before loop).
Test case:
class foo {
public static void main(String argv[]) {
System.out.println("Warmup");
foo F = new foo();
char [] C = new char[100];
for( int i=0; i<100000; i++ ) {
String s = Integer.toString(i);
s.getChars(0,s.length(),C,0);
F.insert(C);
}
System.out.println("Done ");
}
private final Node ROOT = new Node();
private static class Node {
final Node _next[] = new Node[128];
}
public Node insert(char [] C) {
int len = C.length;
Node node = ROOT;
int j = 0;
for(; j < len; j++) {
Node node1 = node._next[C[j]];
if( node1 == null ) break;
node = node1;
}
for(; j < len; j++) {
Node node2 = new Node();
node._next[C[j]] = node2;
node = node2;
}
return node;
}
}
Hi! Long time no bug report - so I thought you might need one. :-)
This one happens with "java_g -server -Xmx512m -Xms512m -Xbatch
-XX:+PrintCompilation -XX:CompileOnly=foo.insert foo" and the included
foo.java, on 1.4.2_03 SparcV9 for sure (and +PrintOptoAssembly shows a
load scheduled before the null-check). I get funny OOM errors with the
product versions of later X86 & Sparc things; not sure if it's the same
crash.
Cliff
------------------------------------------------------------------------
From my putback msg:
The Ideal_DU_postCCP function removes CastPP's and replaces them with
control edges on memory ops. In order to give some scheduling freedom,
it tries to find a least restrictive control input that is also
sufficient to prevent hoisting above any needed null-check. In the case
of CountedLoops, it is willing to use a pre-loop control input. This is
not always correct: if the base value is known not-null but is a merge
at the loop head - at is null-checked on entry AND at the loop bottom -
then the old code would allow the control edge to move up to the
null-check on entry. The memory op could not float up out of the loop
because the base value merges at the loop head.
If we later unrolled the loop, the cloned memory op would then take
control from before the loop (like the original now does) and its base
input from the unrolled prior loop body - which has no merging phi and
whose CastPP was removed before unrolling. Hence the cloned memory op
could float above a needed null test.
Fix is to not lift the control above a CountedLoop, unless the base
value does not merge at the loop head (and is available already
null-checked before loop).
Test case:
class foo {
public static void main(String argv[]) {
System.out.println("Warmup");
foo F = new foo();
char [] C = new char[100];
for( int i=0; i<100000; i++ ) {
String s = Integer.toString(i);
s.getChars(0,s.length(),C,0);
F.insert(C);
}
System.out.println("Done ");
}
private final Node ROOT = new Node();
private static class Node {
final Node _next[] = new Node[128];
}
public Node insert(char [] C) {
int len = C.length;
Node node = ROOT;
int j = 0;
for(; j < len; j++) {
Node node1 = node._next[C[j]];
if( node1 == null ) break;
node = node1;
}
for(; j < len; j++) {
Node node2 = new Node();
node._next[C[j]] = node2;
node = node2;
}
return node;
}
}
- backported by
-
JDK-2149549 Ideal_DU_postCCP not conservative enough
- Resolved
-
JDK-2166320 Ideal_DU_postCCP not conservative enough
- Resolved
-
JDK-2168779 Ideal_DU_postCCP not conservative enough
- Resolved
-
JDK-2149771 Ideal_DU_postCCP not conservative enough
- Closed
- duplicates
-
JDK-6715676 Nortel reports intermittent failure with JDK 1.4.2 on Windows using their Application
- Closed
-
JDK-6527749 JVM Crashed - unhandled implicit exception in compiled code
- Closed
(1 duplicates)