EVALUATION
I'm unable to reproduce this problem, using the example method
shown.
1$ uname -a
SunOS analemma 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-60
1$ /java/re/jdk/1.4.2_07/promoted/latest/binaries/solaris-sparc/bin/java -Xms300m -Xmx768m -XX:MaxPermSize=1940m -jar /java/re/jdk/1.4.2_07/promoted/latest/binaries/solaris-sparc/demo/jfc/Java2D/Java2Demo.jar
2$ /bin/ps -ef | grep 1.4.2
pbk 17527 17526 14 15:14:53 pts/20 0:15 /java/re/jdk/1.4.2_07/promoted/latest/binaries/solaris-sparc/bin/java -Xms300m
2$ pmap 17527
17527: /java/re/jdk/1.4.2_07/promoted/latest/binaries/solaris-sparc/bin/java
....
50000000 34240K read/write/exec [ anon ]
55550000 273088K read/write/exec [ anon ]
80000000 7168K read/write/exec [ anon ]
....
and Java2Demo seems to run just fine.
Another way to know where the various parts of the Java object heap are is to run with -XX:+PrintHeapAtGC, which produces maps like:
Heap before GC invocations=0:
Heap
def new generation total 33152K, used 16043K [0x50000000, 0x52150000, 0x55550000)
eden space 32192K, 49% used [0x50000000, 0x50faafc0, 0x51f70000)
from space 960K, 0% used [0x51f70000, 0x51f70000, 0x52060000)
to space 960K, 0% used [0x52060000, 0x52060000, 0x52150000)
tenured generation total 273088K, used 0K [0x55550000, 0x66000000, 0x80000000)
the space 273088K, 0% used [0x55550000, 0x55550000, 0x55550200, 0x66000000)
compacting perm gen total 7168K, used 6945K [0x80000000, 0x80700000, 0xf9400000)
the space 7168K, 96% used [0x80000000, 0x806c8578, 0x806c8600, 0x80700000)
where you can see that the "compacting perm gen" starts at 0x80000000. (And you can see from the fact that the perm generation is the only that's nearly full that this collection is from a failed attempt to allocate in the perm generation.) Of course, this way of looking at the heap only works if the VM runs long enough to cause a collection, and doesn't hang with the NoSuchMethodError you show.
I've tried other sizes for the -XX:MaxPermSize= to get the permanent generation to start at various other places near the 2^31 boundary. E.g.,
compacting perm gen total 7168K, used 6949K [0x79c00000, 0x7a300000, 0xf9400000)
the space 7168K, 96% used [0x79c00000, 0x7a2c9638, 0x7a2c9800, 0x7a300000)
and
compacting perm gen total 7168K, used 6951K [0x86400000, 0x86b00000, 0xf9400000)
the space 7168K, 96% used [0x86400000, 0x86ac9db0, 0x86ac9e00, 0x86b00000)
to see if *crossing* that boundary was the problem, but I've been unable to reproduce the problem.
Why am I unable to reproduce the problem? Especially that you gave such clear instructions.
We did used to have bugs like this with spaces laid out across the 2^31 boundary, but I think we fixed them all a while ago. We might have inadvertently introduced a new one. But if I can't reproduce the problem it will be hard to track down.
###@###.### 2005-2-25 23:35:10 GMT
I'm now able to reproduce the problem, on a recent JDK-1.6.0 fastdebug build.
We seem to have failed a binary search lookup. Since no garbage collection has happened, this is not a GC problem. I'm reassigning it to the runtime group, even though I think it might be fun to track this one down. I've attached the hs_err file from the fastdebug failure, and the dbx stack trace.
###@###.### 2005-03-01 18:18:56 GMT
I'm pretty sure the problem is this line in symoblOop.hpp:
return (int)(intptr_t(this) - intptr_t(other));
where those casts (that look like constructors!) should be to uintptr_t's, since the symbolOops can be on either side of the sign-bit.
Then there's the cast of the difference to an int, but I think that's okay as long as the symbolOops aren't too far apart, e.g., in 64-bit VMs with huge permanent generations. If no one uses anything except the sign of the result, it might be better to just compute -1, 0, or 1, rather than trying to fit the difference into an int.
###@###.### 2005-03-02 18:37:49 GMT
|
Java