Bug ID: JDK-6309680 hotspot "-d64" throwing Exception thread java.lang.OutOfMemoryError:Java heap space for sol10-b10AMD

EVALUATION As indicated in my previous note, this bug should have been closed as "not a defect", not as a duplicate of 6289964.
25-08-2005
EVALUATION I had added 6289964 in the "See Also" section for informational reasons. This bug cannot be considered a duplicate of 6289964. 6289964 calls for a re-evaluation of the 64-bit heap dilation factor (which is today pegged at 30% based on historical measurements on a set of reference applications) so that the app-server launch scripts need not specify an additional heap sizing parameter when going 64 bit. This bug on the other hand, is a test case, and although it shows up a situation where the default setting suffices for the 32 bit runs, but not for the 64 bit runs on account of their objects being more oop-rich than our design center applications, this is just that -- a test case; not a strategic application that would call for reevaluation of the 30% dilation factor. As such, I would close this as "Not a Bug" rather than as a duplicate of RFE 6289964.
18-08-2005
EVALUATION Hello Basavaraj -- When you run on a machine that has at least 2 cpus and at least 2 GB or RAM you get what we call an ergonomic server collector. The launch script automatically detects this and appends +UseParallelGC and a MaxHeapSize setting determined from the available memory on the machine. In this case, this results in: % /net/koori.sfbay/onestop/jdk/1.6.0/latest/binaries/solaris-i586/bin/java -XX:+PrintCommandLineFlags -version -XX:MaxHeapSize=536619008 -XX:+PrintCommandLineFlags -XX:+UseParallelGC java version "1.6.0-ea" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b47) Java HotSpot(TM) Server VM (build 1.6.0-ea-b47, mixed mode) This would be the same for JDK 5.0 as well. As Gary has indicated in the bug report's comments/evaluation section this larger heap setting allows the test to complete. On the other hand, if you run on a machine with less than 2 cpus or less than 2 GB or RAM, and do not explicitly specify otherwise, you will get the default single-threaded non-ergonomic collector which has a maximum default heap size of 64 MB in 32 bit mode and of roughly 30% more (i.e. about 80 MB) in 64-bit mode. As Gary indicated, that much heap is insuffficient for running your program to completion in 64-bit mode, and you end up getting an out-of-memory error. In general, default heap size settings are chosen using some set of benchmarks and various figures of merit in a design center (which changes from release to release). That default setting may not be suitable in all cases, and in such situations the application (i.e. in this case your test) would need to provide an appropriate -Xmx value. Based on this evaluation, I would close your bug report as "Not a bug". There is one thing I want to verify with you for sure before I do so, though: In my understanding, the original bug report stated that you ran this test on Machine X running s10u4 and the test passed. You then upgraded Machine X to s10u10 and the test failed with an out of memory error. I would _not_ expect that to happen. What I would expect happened is that you ran on a different Machine Y running S10u10, and this machine had less than 2 CPUs or 2 GB of RAM and as a result you got a different collector with a smaller default heap size which caused the test to fail with an OOM. Could you confirm that Machine X and Machine Y above were different, and could you point me to the respective machines so that i may confirm that the ergonomics of the JVM are causing the issue that you encountered. In other words, please send me a pointer to both the machine X on which the test passed and machine Y on which the test failed. Alternatively, as I did above, please run: % java -d64 -XX:+PrintCommandLineFlags -version as well as % psrinfo -v % whatami on each of the two machines and confirm what I conjectured above. Then close the bug report you opened as "Not a bug", or let me know. Thanks. -- ramki.
18-08-2005
EVALUATION Please see Gary's note above on the reproducibility of the OOM on s10u1b04 as well. Can the submitter please provide us with access to a machine that exhibits this issue, namely where the OOM error does _not_ occur. We are marking this bug incomplete until such time and will close it as not reproducible otherwise. The basic problem, we believe, is that the test requires more than the default heap size (80 MB) to run 64-bit java. If it ever succeeded in running with that much heap, it must be because it's right at the edge and some small thread reshuffling/interleaving allows one to squeeze through. It can be argued that the "dilation factor" of 30% used for sizing up defaults from 32 bit to 64 bit is considered too small, but that is a different bug, for which an RFE (6289964) exists and which will be addressed in the Mustang time-frame.
17-08-2005
WORK AROUND -Xmx128m
17-08-2005
EVALUATION Running with -XX:+UseSerialGC on server class machines or defaults on non server class machines causes OOM exceptions to be thrown on sol10_u1-b10 rip-make -env tiger -hotspot "-d64 -XX:+UseSerialGC -XX:+PrintHeapAtGC -XX:+PrintGCDetails" -v all >& /scratch/bug-6309680/serialheap-s10u1b04.log I BFU'd my machine back to b04 build /ws/on10-patch/archives/daily_builds/G10U1B4-050316-daily/archives/i386/nightly Not sure this is the exact build version match though.. I still see the OOM error that bug submitter sees with b10 build... So, appears this issue is always seen for me. However, bumping up the -Xmx128m makes the issue go away.. I guess the only way to truely test for error to occur in b04 build is to do a fresh install. I do not have the logs for the their issue on b04 with PrintHeapAtGC.
17-08-2005
EVALUATION Problem may be a config/install issue.. Look at mem and swap... I would assume issue would go away if they increase swap.. Normally swap is always 2x installed mem.. I have not tested to see how much mem is needed to run testsuite yet, but I would assume they are running out of physical mem.. Not a JDK problem.. Regards, Gary /usr/dist/local/exe/whatami DATE: Wed Aug 17 13:00:01 BST 2005 USER: root HOSTNAME: elxl0 = opteron1 IP ADDRESS: elxl0 = 129.156.233.109 MODEL: i86pc FRAME BUFFER(S): unknown SunOS RELEASE: 5.10 TYPE: unknown (/=ufs, swap=spec, /usr=ufs, /home=unknown) MEMORY: 1023MB SWAP: 1085.9MB total, 208.2MB used, 877.7MB available LOAD AVERAGE: 0.01, 0.01, 0.01 DNS DOMAINNAME: ireland.sun.com NIS DOMAINNAME: dublin.ireland.sun.com DEFAULT PRINTER: none ETHERNET ADDRESS: 0:1:2:cc:92:44 HOSTID: 2eed616b DISK: c0d0s2 unknown (30036MB unformatted) RAW PARTITION: c0d0s2s1 (512MB) RAW PARTITION: c0d0s2s8 (0MB) RAW PARTITION: c0d0s2s9 (1MB) FLOPPY: fd0 (3.5-inch floppy) FLOPPY: fd1 (3.5-inch floppy) # # psrinfo -v Status of virtual processor 0 as of: 08/17/2005 13:02:24 on-line since 08/11/2005 15:12:57. The i386 processor operates at 1800 MHz, and has an i387 compatible floating point processor. # isainfo amd64 i386 Updation : ========== I ran with the following configeration machine with sol10-b11 amd machine: DATE: Wed Aug 17 19:48:38 IST 2005 USER: bj159556 HOSTNAME: elxl0 = urti020 IP ADDRESS: elxl0 = 10.12.152.133 MODEL: i86pc FRAME BUFFER(S): unknown SunOS RELEASE: 5.10 TYPE: homeless FILESERVER: hs-cblr03-02.india MEMORY: 1023MB SWAP: 4810.6MB total, 397.1MB used, 4413.5MB available LOAD AVERAGE: 1.12, 0.98, 0.49 DNS DOMAINNAME: India.Sun.COM NIS DOMAINNAME: blr03-01.India.Sun.COM SOFTWARE SERVER(S): sd-cblr03-01,sd-cblr03-02,mum-user,sr-cnwd03-02,joggers,prestige DEFAULT PRINTER: none ETHERNET ADDRESS: 0:1:3:28:91:c9 HOSTID: 0f865311 FLOPPY: fd0 (3.5-inch floppy) FLOPPY: fd1 (3.5-inch floppy) I have used the flag as "-XX:+PrintGCDetails" And attached the compressed log file. Stiill I am getting Exception in thread "Thread-7" java.lang.OutOfMemoryError: Java heap space I used the command as rip-make -env tiger -hotspot "-d64 -XX:+PrintGCDetails" -v all 2>&1 \| tee urti020_xxflagGc.log
17-08-2005