From andrey.petrusenko at sun.com Mon May 4 08:32:14 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 04 May 2009 15:32:14 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 11 new changesets Message-ID: <20090504153238.163FEEE38@hg.openjdk.java.net> Changeset: 3672e1dac765 Author: kvn Date: 2009-04-27 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3672e1dac765 6834142: method->print_codes(): Error: ShouldNotReachHere() Summary: Restore the call to Bytecodes::java_code() in BytecodePrinter::print_attributes(). Reviewed-by: jrose ! src/share/vm/interpreter/bytecodeTracer.cpp Changeset: 27e8e660fbd0 Author: kvn Date: 2009-04-27 12:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/27e8e660fbd0 Merge Changeset: c8379544879a Author: ohair Date: 2009-04-29 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c8379544879a 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: kvn - make/jprt.config ! make/jprt.properties Changeset: bc47cdb8966c Author: xdono Date: 2009-04-23 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bc47cdb8966c Added tag jdk7-b56 for changeset a3fd9e40ff2e ! .hgtags Changeset: 451fd2abeda8 Author: jcoomes Date: 2009-04-29 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/451fd2abeda8 Merge Changeset: f4cbf78110c7 Author: jcoomes Date: 2009-04-29 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f4cbf78110c7 6834202: Bump the HS16 build number to 02 Reviewed-by: jmasa ! make/hotspot_version Changeset: 61c5604c8422 Author: jcoomes Date: 2009-04-30 09:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/61c5604c8422 Merge - make/jprt.config Changeset: 45463a04ca27 Author: kvn Date: 2009-04-29 12:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/45463a04ca27 6834177: Running jsynprog on Solaris Nevada can cause JVM crash Summary: Use CodeCache buffer blob instead of static buffer in AdapterHandlerLibrary. Reviewed-by: never ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: f36f12d01311 Author: kvn Date: 2009-04-30 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f36f12d01311 Merge Changeset: af5d39ca39a3 Author: kvn Date: 2009-04-30 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/af5d39ca39a3 6835796: Fedora 9 linux_i586-fastdebug-c2-runThese_Xcomp times out Summary: Switch off GCC 4.3.0 optimized compilation for mulnode.o. Reviewed-by: johnc ! make/jprt.properties ! make/linux/makefiles/gcc.make Changeset: 51285b431bb2 Author: apetrusenko Date: 2009-05-04 02:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/51285b431bb2 Merge From john.cuthbertson at sun.com Mon May 4 17:56:37 2009 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Tue, 05 May 2009 00:56:37 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6490395: G1: Tidy up command line flags. Message-ID: <20090505005640.A70F9EE72@hg.openjdk.java.net> Changeset: 20c6f43950b5 Author: johnc Date: 2009-04-30 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/20c6f43950b5 6490395: G1: Tidy up command line flags. Summary: Change G1 flag names to be more consistent and disable some in 'product' mode. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From john.cuthbertson at sun.com Wed May 6 01:14:04 2009 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Wed, 06 May 2009 08:14:04 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6833576: G1: assert illegal index, growableArray.hpp:186 Message-ID: <20090506081410.831C8E11E@hg.openjdk.java.net> Changeset: a2957df801a1 Author: johnc Date: 2009-05-05 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a2957df801a1 6833576: G1: assert illegal index, growableArray.hpp:186 Summary: The code that calculates the heap region index for an object address incorrectly used signed arithmetic. Reviewed-by: jcoomes, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp From Y.S.Ramakrishna at Sun.COM Wed May 6 14:56:28 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Wed, 06 May 2009 14:56:28 -0700 Subject: Strange long ParNew collections In-Reply-To: <4A017D35.7000208@mag.se> References: <4A017D35.7000208@mag.se> Message-ID: <4A02078C.4080904@Sun.COM> This may or may not be a cause of the sudden spikes in ParNew collection, but I'd suggest using the survivor spaces to age objects for at least a few collections before promoting to the old gen. This reduces pressure on the old gen allocation (during scavenge) improving scavenges and on CMS collection as well. I'd suggest trying -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=4 to start off with and iterate based on data from -XX:+PrintTenuringDistribution. It is possible that the promotion of very short-lived objects fragments the old gen and causes old gen allocation (for promotion) to slow down. It can also cause lots of mutation in the old gen and adversely affect card-scanning times further slowing down scavenges. -- ramki On 05/06/09 05:06, Kaj Nygren wrote: > Hi, > > We are having problems with occational long ParNew pauses in our > application running on a Jboss server. The server runs well for most of > the time but sometimes we get ParNew collections that can take up to 120 > seconds. Most of the time we have several consecutive slow collections, > which are more or less killing the server under high load. > > We are using JDK 1.5.0_16 on Windows Server 2003, and are using ParNew + > Concurrent CMS. > > Our GC configuration is: > > wrapper.java.additional.1=-Dprogram.name=run.bat > wrapper.java.additional.2=-server > wrapper.java.additional.3=-Xms19000m > wrapper.java.additional.4=-Xmx19000m > wrapper.java.additional.5="-XX:NewSize=1000m" > wrapper.java.additional.6="-XX:MaxNewSize=1000m" > wrapper.java.additional.7="-XX:MaxPermSize=256m" > wrapper.java.additional.8="-XX:PermSize=256m" > wrapper.java.additional.11="-Xloggc:c:\mygclog.gc" > wrapper.java.additional.12="-XX:+UseConcMarkSweepGC" > wrapper.java.additional.13="-XX:+PrintGCDetails" > wrapper.java.additional.14="-XX:-PrintTenuringDistribution" > wrapper.java.additional.15="-XX:+PrintHeapAtGC" > wrapper.java.additional.16="-XX:+DisableExplicitGC" > wrapper.java.additional.17="-XX:+PrintGCTimeStamps" > wrapper.java.additional.18="-XX:CMSInitiatingOccupancyFraction=50" > wrapper.java.additional.19="-XX:+CMSIncrementalMode" > wrapper.java.additional.20="-XX:+CMSIncrementalPacing" > wrapper.java.additional.21="-verbose:gc" > > Usually ParNew is quick as can be seen here: > > 614276,653: [ParNew: 935058K->0K(1023040K), 0,0624699 secs] > 12383872K->11459948K(19455040K) icms_dc=22 Heap after gc invocations=57822: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 11459948K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112069K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 0,0628860 secs] > > But suddenly it becomes really slow: > > 620659,717: [ParNew: 1022080K->0K(1023040K), 1,3313817 secs] > 12688913K->11692925K(19455040K) icms_dc=10 Heap after gc invocations=58587: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 11692925K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112098K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 1,3319554 secs] > 620663,221: [GC {Heap before gc invocations=58587: > par new generation total 1023040K, used 1022080K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 11692925K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > 620663,222: [ParNew: 1022080K->0K(1023040K), 10,2909893 secs] > 12715005K->11936864K(19455040K) icms_dc=10 Heap after gc invocations=58588: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 11936864K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 10,2915548 secs] > 620676,392: [GC {Heap before gc invocations=58588: > par new generation total 1023040K, used 1022080K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 11936864K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > 620676,392: [ParNew: 1022080K->0K(1023040K), 3,8905950 secs] > 12958944K->12020225K(19455040K) icms_dc=10 Heap after gc invocations=58589: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 12020225K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 3,8911113 secs] > 620682,667: [GC {Heap before gc invocations=58589: > par new generation total 1023040K, used 1022080K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 12020225K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112112K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > 620682,668: [ParNew: 1022080K->0K(1023040K), 9,4186088 secs] > 13042305K->12214571K(19455040K) icms_dc=10 Heap after gc invocations=58590: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 12214571K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112112K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 9,4191551 secs] > > We also have problems with occational promotion failed, which I assume > is due to fragmentation. > I have attatched a longer log, which shows this behaviour and ends with > a promotion failed. > > Does anybody have a glue as to what is going wrong, and how we can > change our gc configuration to reduce the problems? > Any help is greatly appreciated! > > Regards > > Kaj Nygren > kaj at mag.se > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Wed May 6 15:06:52 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 06 May 2009 15:06:52 -0700 Subject: Strange long ParNew collections In-Reply-To: <4A017D35.7000208@mag.se> References: <4A017D35.7000208@mag.se> Message-ID: <4A0209FC.3030106@Sun.COM> Kaj, I don't see anything in the logs that points to a specific problem. Why are you using CMSIncrementalMode? By default the CMS collector promotes all objects that survive 1 minor collection (into the tenured generation). You might find it useful to use larger survivor spaces and a larger tenuring threshold. See http://blogs.sun.com/jonthecollector/entry/the_fault_with_defaults for some suggestions of values to try. You might also benefit from a larger young. Have you tried larger values? 2g? Or maybe even 4g Jon On 05/06/09 05:06, Kaj Nygren wrote: > Hi, > > We are having problems with occational long ParNew pauses in our > application running on a Jboss server. The server runs well for most of > the time but sometimes we get ParNew collections that can take up to 120 > seconds. Most of the time we have several consecutive slow collections, > which are more or less killing the server under high load. > > We are using JDK 1.5.0_16 on Windows Server 2003, and are using ParNew + > Concurrent CMS. > > Our GC configuration is: > > wrapper.java.additional.1=-Dprogram.name=run.bat > wrapper.java.additional.2=-server > wrapper.java.additional.3=-Xms19000m > wrapper.java.additional.4=-Xmx19000m > wrapper.java.additional.5="-XX:NewSize=1000m" > wrapper.java.additional.6="-XX:MaxNewSize=1000m" > wrapper.java.additional.7="-XX:MaxPermSize=256m" > wrapper.java.additional.8="-XX:PermSize=256m" > wrapper.java.additional.11="-Xloggc:c:\mygclog.gc" > wrapper.java.additional.12="-XX:+UseConcMarkSweepGC" > wrapper.java.additional.13="-XX:+PrintGCDetails" > wrapper.java.additional.14="-XX:-PrintTenuringDistribution" > wrapper.java.additional.15="-XX:+PrintHeapAtGC" > wrapper.java.additional.16="-XX:+DisableExplicitGC" > wrapper.java.additional.17="-XX:+PrintGCTimeStamps" > wrapper.java.additional.18="-XX:CMSInitiatingOccupancyFraction=50" > wrapper.java.additional.19="-XX:+CMSIncrementalMode" > wrapper.java.additional.20="-XX:+CMSIncrementalPacing" > wrapper.java.additional.21="-verbose:gc" > > Usually ParNew is quick as can be seen here: > > 614276,653: [ParNew: 935058K->0K(1023040K), 0,0624699 secs] > 12383872K->11459948K(19455040K) icms_dc=22 Heap after gc invocations=57822: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 11459948K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112069K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 0,0628860 secs] > > But suddenly it becomes really slow: > > 620659,717: [ParNew: 1022080K->0K(1023040K), 1,3313817 secs] > 12688913K->11692925K(19455040K) icms_dc=10 Heap after gc invocations=58587: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 11692925K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112098K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 1,3319554 secs] > 620663,221: [GC {Heap before gc invocations=58587: > par new generation total 1023040K, used 1022080K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 11692925K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > 620663,222: [ParNew: 1022080K->0K(1023040K), 10,2909893 secs] > 12715005K->11936864K(19455040K) icms_dc=10 Heap after gc invocations=58588: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 11936864K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 10,2915548 secs] > 620676,392: [GC {Heap before gc invocations=58588: > par new generation total 1023040K, used 1022080K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 11936864K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > 620676,392: [ParNew: 1022080K->0K(1023040K), 3,8905950 secs] > 12958944K->12020225K(19455040K) icms_dc=10 Heap after gc invocations=58589: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 12020225K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112106K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 3,8911113 secs] > 620682,667: [GC {Heap before gc invocations=58589: > par new generation total 1023040K, used 1022080K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > concurrent mark-sweep generation total 18432000K, used 12020225K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112112K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > 620682,668: [ParNew: 1022080K->0K(1023040K), 9,4186088 secs] > 13042305K->12214571K(19455040K) icms_dc=10 Heap after gc invocations=58590: > par new generation total 1023040K, used 0K [0x000000007fff0000, > 0x00000000be7f0000, 0x00000000be7f0000) > eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, > 0x00000000be610000) > from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, > 0x00000000be7f0000) > to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, > 0x00000000be700000) > concurrent mark-sweep generation total 18432000K, used 12214571K > [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) > concurrent-mark-sweep perm gen total 262144K, used 112112K > [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) > } > , 9,4191551 secs] > > We also have problems with occational promotion failed, which I assume > is due to fragmentation. > I have attatched a longer log, which shows this behaviour and ends with > a promotion failed. > > Does anybody have a glue as to what is going wrong, and how we can > change our gc configuration to reduce the problems? > Any help is greatly appreciated! > > Regards > > Kaj Nygren > kaj at mag.se > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Thu May 7 09:10:22 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Thu, 07 May 2009 09:10:22 -0700 Subject: Strange long ParNew collections In-Reply-To: <4A029FC4.1090303@mag.se> References: <4A017D35.7000208@mag.se> <4A0209FC.3030106@Sun.COM> <4A029FC4.1090303@mag.se> Message-ID: <4A0307EE.1050204@Sun.COM> Kaj, iCMS may have worked better for you because it might kick off a collection earlier. But iCMS was intended for use on 1 or 2 processor machines where doing work concurrently would hog one (maybe the only one) processor so would not feel very concurrent to the application. I think your use of the lower initiating occupancy would have gotten you the result you needed. iCMS generally runs longer and leaves more floating garbage (dead objects that are not recognized as garbage until the next collection). I'd suggest that you do some testing without the incremental mode and with the larger survivor spaces and tenuring threshold and see how that does. The concurrent mode failures can often be reduced when the survivor spaces are used. Jon Kaj Nygren wrote: >Hi Jon, > >Thanks for your input! > >Well it was around a year ago that we turned on incremental mode, but if >memory serves me right we had problems with getting "Concurrent Mode >Failure" rather often (probably CMS kicking in to late and not keeping up). > >It is an 8 processor machine but the application is keeping it rather >busy. We searched around for possible solutions and found several >sources that recommended running iCMS, and tuning the threshold to start >CMS gc earlier. We turned on iCMS and that helped. The application has >changed a bit since then so maybe that's not needed anymore though. >(This might have been a bogus change by us though, gc internals is still >a bit voodoo for me, although I've tried to read up as much as I can >about it :) > >We will start by specifying a SurvivorRatio and a TenuringThreshold, and >see if that helps. After that if that's needed I'll try increasing the >spaces as well. > >/Kaj > > >Jon Masamitsu skrev: > > >>Kaj, >> >>I don't see anything in the logs that points to >>a specific problem. >> >>Why are you using CMSIncrementalMode? >> >>By default the CMS collector promotes all >>objects that survive 1 minor collection >>(into the tenured generation). You might >>find it useful to use larger survivor >>spaces and a larger tenuring threshold. >>See >> >>http://blogs.sun.com/jonthecollector/entry/the_fault_with_defaults >> >>for some suggestions of values to try. You might also benefit >>from a larger young. Have you tried larger values? 2g? Or maybe >>even 4g >> >>Jon >> >>On 05/06/09 05:06, Kaj Nygren wrote: >> >> >> >>>Hi, >>> >>>We are having problems with occational long ParNew pauses in our >>>application running on a Jboss server. The server runs well for most of >>>the time but sometimes we get ParNew collections that can take up to 120 >>>seconds. Most of the time we have several consecutive slow collections, >>>which are more or less killing the server under high load. >>> >>>We are using JDK 1.5.0_16 on Windows Server 2003, and are using ParNew + >>>Concurrent CMS. >>> >>>Our GC configuration is: >>> >>>wrapper.java.additional.1=-Dprogram.name=run.bat >>>wrapper.java.additional.2=-server >>>wrapper.java.additional.3=-Xms19000m >>>wrapper.java.additional.4=-Xmx19000m >>>wrapper.java.additional.5="-XX:NewSize=1000m" >>>wrapper.java.additional.6="-XX:MaxNewSize=1000m" >>>wrapper.java.additional.7="-XX:MaxPermSize=256m" >>>wrapper.java.additional.8="-XX:PermSize=256m" >>>wrapper.java.additional.11="-Xloggc:c:\mygclog.gc" >>>wrapper.java.additional.12="-XX:+UseConcMarkSweepGC" >>>wrapper.java.additional.13="-XX:+PrintGCDetails" >>>wrapper.java.additional.14="-XX:-PrintTenuringDistribution" >>>wrapper.java.additional.15="-XX:+PrintHeapAtGC" >>>wrapper.java.additional.16="-XX:+DisableExplicitGC" >>>wrapper.java.additional.17="-XX:+PrintGCTimeStamps" >>>wrapper.java.additional.18="-XX:CMSInitiatingOccupancyFraction=50" >>>wrapper.java.additional.19="-XX:+CMSIncrementalMode" >>>wrapper.java.additional.20="-XX:+CMSIncrementalPacing" >>>wrapper.java.additional.21="-verbose:gc" >>> >>>Usually ParNew is quick as can be seen here: >>> >>>614276,653: [ParNew: 935058K->0K(1023040K), 0,0624699 secs] >>>12383872K->11459948K(19455040K) icms_dc=22 Heap after gc invocations=57822: >>>par new generation total 1023040K, used 0K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>>concurrent mark-sweep generation total 18432000K, used 11459948K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112069K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>} >>>, 0,0628860 secs] >>> >>>But suddenly it becomes really slow: >>> >>>620659,717: [ParNew: 1022080K->0K(1023040K), 1,3313817 secs] >>>12688913K->11692925K(19455040K) icms_dc=10 Heap after gc invocations=58587: >>>par new generation total 1023040K, used 0K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>>concurrent mark-sweep generation total 18432000K, used 11692925K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112098K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>} >>>, 1,3319554 secs] >>>620663,221: [GC {Heap before gc invocations=58587: >>>par new generation total 1023040K, used 1022080K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>>concurrent mark-sweep generation total 18432000K, used 11692925K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112106K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>620663,222: [ParNew: 1022080K->0K(1023040K), 10,2909893 secs] >>>12715005K->11936864K(19455040K) icms_dc=10 Heap after gc invocations=58588: >>>par new generation total 1023040K, used 0K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>>concurrent mark-sweep generation total 18432000K, used 11936864K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112106K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>} >>>, 10,2915548 secs] >>>620676,392: [GC {Heap before gc invocations=58588: >>>par new generation total 1023040K, used 1022080K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>>concurrent mark-sweep generation total 18432000K, used 11936864K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112106K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>620676,392: [ParNew: 1022080K->0K(1023040K), 3,8905950 secs] >>>12958944K->12020225K(19455040K) icms_dc=10 Heap after gc invocations=58589: >>>par new generation total 1023040K, used 0K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>>concurrent mark-sweep generation total 18432000K, used 12020225K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112106K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>} >>>, 3,8911113 secs] >>>620682,667: [GC {Heap before gc invocations=58589: >>>par new generation total 1023040K, used 1022080K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 100% used [0x000000007fff0000, 0x00000000be610000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>>concurrent mark-sweep generation total 18432000K, used 12020225K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112112K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>620682,668: [ParNew: 1022080K->0K(1023040K), 9,4186088 secs] >>>13042305K->12214571K(19455040K) icms_dc=10 Heap after gc invocations=58590: >>>par new generation total 1023040K, used 0K [0x000000007fff0000, >>>0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, 0x000000007fff0000, >>>0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>>0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>>0x00000000be700000) >>>concurrent mark-sweep generation total 18432000K, used 12214571K >>>[0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>>concurrent-mark-sweep perm gen total 262144K, used 112112K >>>[0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>>} >>>, 9,4191551 secs] >>> >>>We also have problems with occational promotion failed, which I assume >>>is due to fragmentation. >>>I have attatched a longer log, which shows this behaviour and ends with >>>a promotion failed. >>> >>>Does anybody have a glue as to what is going wrong, and how we can >>>change our gc configuration to reduce the problems? >>>Any help is greatly appreciated! >>> >>>Regards >>> >>>Kaj Nygren >>>kaj at mag.se >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>hotspot-gc-use mailing list >>>hotspot-gc-use at openjdk.java.net >>>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>> >>> >>> >>_______________________________________________ >>hotspot-gc-use mailing list >>hotspot-gc-use at openjdk.java.net >>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> >> > >_______________________________________________ >hotspot-gc-use mailing list >hotspot-gc-use at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at sun.com Thu May 7 18:47:23 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 08 May 2009 01:47:23 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 3 new changesets Message-ID: <20090508014741.1DE7AE5BD@hg.openjdk.java.net> Changeset: 81a249214991 Author: poonam Date: 2009-05-04 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/81a249214991 6829234: Refix 6822407 and 6812971 Summary: Fixes two SA issues 6822407 and 6812971 Reviewed-by: swamyv, acorn, kvn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changeset: c8f1f4de26c9 Author: kamg Date: 2009-05-07 11:44 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c8f1f4de26c9 Merge Changeset: a58ad611cc63 Author: jcoomes Date: 2009-05-07 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a58ad611cc63 Merge From john.coomes at sun.com Fri May 8 02:45:23 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 08 May 2009 09:45:23 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 5 new changesets Message-ID: <20090508094537.1694FE5FC@hg.openjdk.java.net> Changeset: 2b25645dab33 Author: never Date: 2009-05-04 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2b25645dab33 6837224: libsaproc.so on linux needs version of 6799141 Reviewed-by: kvn ! agent/src/os/linux/Makefile Changeset: 36ee9b69616e Author: cfang Date: 2009-05-05 11:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/36ee9b69616e 6833879: Assigning positive zero is ignored when old value is negative zero Summary: Don't perform CMOVE identity optimization for floating point types Reviewed-by: kvn, never ! src/share/vm/opto/connode.cpp Changeset: cecd04fc6f93 Author: twisti Date: 2009-05-06 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cecd04fc6f93 6837011: SIGSEGV in PhaseIdealLoop in 32bit jvm Summary: The CR's test crashes with SIGSEGV when running with "-server -Xcomp" using using 32bit jvm. Reviewed-by: kvn, never, rasbold ! src/share/vm/opto/divnode.cpp + test/compiler/6837011/Test6837011.java Changeset: f96f285ed3dd Author: never Date: 2009-05-06 17:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f96f285ed3dd 6838154: make/linux/makefiles/sa.make needs hash-style fix Reviewed-by: kvn, jrose ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: 9b3a41ccc927 Author: kvn Date: 2009-05-07 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9b3a41ccc927 Merge From Igor.Veresov at Sun.COM Fri May 8 11:51:02 2009 From: Igor.Veresov at Sun.COM (Igor Veresov) Date: Fri, 08 May 2009 11:51:02 -0700 Subject: Request for review(XXS): 6838842 NUMA allocator: Segfault during startup on Linux Message-ID: <4A047F16.1050506@sun.com> The semantics of os::free_memory() has changed with the fix for 6541756 (Reduce executable C-heap). This function is used in the NUMA-aware allocator to free pages. Instead, now it does an mmap(PROT_NONE), which causes the VM to trap on the next access. The fix is to change this function to have its original semantics. Webrev: http://cr.openjdk.java.net/~iveresov/6838842/webrev.00 From danhicks at ieee.org Sat May 9 18:26:36 2009 From: danhicks at ieee.org (Dan Hicks) Date: Sat, 09 May 2009 20:26:36 -0500 Subject: Info wanted on GC algorithms In-Reply-To: References: Message-ID: <4A062D4C.2090708@ieee.org> Where would be the best place to look for a general description of the (reportedly) 3.5 different GC algorithms/modes in hotspot? Not looking for gory details, just a general outline. -- Dan Hicks Change your thoughts and you change your world. --Norman Vincent Peal From Peter.Kessler at Sun.COM Sat May 9 18:32:47 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Sat, 09 May 2009 18:32:47 -0700 Subject: Info wanted on GC algorithms In-Reply-To: <4A062D4C.2090708@ieee.org> References: <4A062D4C.2090708@ieee.org> Message-ID: <4A062EBF.6010503@Sun.COM> Dan Hicks wrote: > Where would be the best place to look for a general description of the > (reportedly) 3.5 different GC algorithms/modes in hotspot? Not looking > for gory details, just a general outline. A good place to start is Our Collectors http://blogs.sun.com/jonthecollector/entry/our_collectors and for deeper reading, there's Memory Management in the Java HotSpot Virtual Machine http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf Come back with more questions! ... peter From Y.S.Ramakrishna at Sun.COM Sat May 9 18:37:45 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Sat, 09 May 2009 18:37:45 -0700 Subject: Info wanted on GC algorithms In-Reply-To: <4A062D4C.2090708@ieee.org> References: <4A062D4C.2090708@ieee.org> Message-ID: <4A062FE9.2090603@sun.com> If you point yr browser to:- http://java.sun.com/javase/technologies/hotspot/gc/ it's the memory management white-paper, viz. :- http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf It doesn't however contain a description of the latest, namely G1 (experimental in 6u14), for which you'd get the gory details in:- http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf -- ramki Dan Hicks wrote: > Where would be the best place to look for a general description of the > (reportedly) 3.5 different GC algorithms/modes in hotspot? Not > looking for gory details, just a general outline. > From igor.veresov at sun.com Mon May 11 18:50:29 2009 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Tue, 12 May 2009 01:50:29 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6484957: G1: parallel concurrent refinement; ... Message-ID: <20090512015036.49338EA54@hg.openjdk.java.net> Changeset: 315a5d70b295 Author: iveresov Date: 2009-05-11 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/315a5d70b295 6484957: G1: parallel concurrent refinement 6826318: G1: remove traversal-based refinement code Summary: Removed traversal-based refinement code as it's no longer used. Made the concurrent refinement (queue-based) parallel. Reviewed-by: tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp From john.coomes at sun.com Thu May 14 22:19:31 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:19:31 +0000 Subject: hg: jdk7/hotspot-gc: 2 new changesets Message-ID: <20090515051931.EE7CEEEDD@hg.openjdk.java.net> Changeset: 030142474602 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/030142474602 Added tag jdk7-b58 for changeset 59b497130f82 ! .hgtags Changeset: 0d76c4da605f Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/0d76c4da605f Added tag jdk7-b59 for changeset 030142474602 ! .hgtags From john.coomes at sun.com Thu May 14 22:23:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:23:26 +0000 Subject: hg: jdk7/hotspot-gc/corba: 4 new changesets Message-ID: <20090515052330.5B45AEEE2@hg.openjdk.java.net> Changeset: e149090eb21a Author: tbell Date: 2009-05-04 18:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/e149090eb21a 6529590: flaw in com.sun.corba.se.impl.presentation.rmi.IDLNameTranslatorImpl Reviewed-by: darcy ! make/com/sun/corba/se/sources/Makefile ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/first.set ! src/share/classes/com/sun/tools/corba/se/idl/follow.set ! src/share/classes/com/sun/tools/corba/se/idl/grammar.idl ! src/share/classes/com/sun/tools/corba/se/idl/grammar3.idl ! src/share/classes/com/sun/tools/corba/se/idl/idl.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 2e3b8edab3ef Author: tbell Date: 2009-05-04 22:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/2e3b8edab3ef Merge Changeset: 7e6b2b55c00c Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/7e6b2b55c00c Added tag jdk7-b58 for changeset 2e3b8edab3ef ! .hgtags Changeset: e9ba2b962ddf Author: vasya Date: 2009-05-14 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/e9ba2b962ddf Added tag jdk7-b59 for changeset 7e6b2b55c00c ! .hgtags From john.coomes at sun.com Thu May 14 22:30:22 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:30:22 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: 4 new changesets Message-ID: <20090515053029.2963BEEE7@hg.openjdk.java.net> Changeset: 3abf80631f99 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/3abf80631f99 6588002: XSLTProcessorApplet still allows reading from forbidden URLs Reviewed-by: darcy - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: 13bf67d8c634 Author: tbell Date: 2009-05-04 22:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/13bf67d8c634 Merge - src/share/classes/com/sun/org/apache/xalan/internal/client/XSLTProcessorApplet.java - src/share/classes/com/sun/org/apache/xalan/internal/client/package.html Changeset: 75113d7ce083 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/75113d7ce083 Added tag jdk7-b58 for changeset 13bf67d8c634 ! .hgtags Changeset: 748976d69503 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/748976d69503 Added tag jdk7-b59 for changeset 75113d7ce083 ! .hgtags From john.coomes at sun.com Thu May 14 22:34:28 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:34:28 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: 4 new changesets Message-ID: <20090515053434.6C2D8EEEC@hg.openjdk.java.net> Changeset: 42dfec6871f6 Author: tbell Date: 2009-05-04 21:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/42dfec6871f6 6658158: Mutable statics in SAAJ (findbugs) 6658163: txw2.DatatypeWriter.BUILDIN is a mutable static (findbugs) Reviewed-by: darcy ! src/share/classes/com/sun/codemodel/internal/JClassContainer.java ! src/share/classes/com/sun/codemodel/internal/JDefinedClass.java ! src/share/classes/com/sun/codemodel/internal/JForEach.java ! src/share/classes/com/sun/codemodel/internal/JMethod.java ! src/share/classes/com/sun/codemodel/internal/JMods.java ! src/share/classes/com/sun/codemodel/internal/util/SingleByteEncoder.java ! src/share/classes/com/sun/codemodel/internal/util/Surrogate.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/AttachmentPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SAAJMetaFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPDocumentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPPartImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CDATAImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/CommentImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/TextImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/name/NameImpl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/HeaderElement1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Message1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Detail1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Envelope1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/RejectDoctypeSaxFilter.java ! src/share/classes/com/sun/xml/internal/messaging/saaj/util/transform/EfficientStreamingTransformer.java ! src/share/classes/com/sun/xml/internal/txw2/DatatypeWriter.java ! src/share/classes/com/sun/xml/internal/txw2/Document.java Changeset: 5fb4fbea81c3 Author: tbell Date: 2009-05-04 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/5fb4fbea81c3 Merge Changeset: f64566bf4c2b Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/f64566bf4c2b Added tag jdk7-b58 for changeset 5fb4fbea81c3 ! .hgtags Changeset: 4fa7398559d0 Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/4fa7398559d0 Added tag jdk7-b59 for changeset f64566bf4c2b ! .hgtags From john.coomes at sun.com Thu May 14 22:39:46 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:39:46 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 27 new changesets Message-ID: <20090515054534.95602EEF1@hg.openjdk.java.net> Changeset: b056c42ea5b4 Author: tbell Date: 2009-05-04 18:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b056c42ea5b4 6837214: Update JDK7 man pages Reviewed-by: darcy, bpatel, tbell Contributed-by: jacob.royal at sun.com ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/apt.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/apt.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/javaws.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: a33222e53611 Author: prr Date: 2009-04-02 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a33222e53611 6753173: No need to read all the TrueType 'post' table to get underline info Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/TrueTypeFont.java Changeset: e3b4eb55a696 Author: lana Date: 2009-04-08 15:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e3b4eb55a696 Merge - make/common/shared/Compiler.gmk - make/jprt.config - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: e61d93fc8ed1 Author: mchung Date: 2009-04-14 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e61d93fc8ed1 6818072: Load Ductus using Class.forName if exist instead of using the service loader Summary: First attempt Class.forName to load Ductus class before using service loader Reviewed-by: flar, prr ! src/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: d609ae2faac2 Author: jgodinez Date: 2009-04-15 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d609ae2faac2 6827989: Use Unsafe.copyMemory for array->Unsafe copy operations in RenderBuffer Reviewed-by: campbell, flar Contributed-by: linuxhippy ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/java2d/pipe/RenderBuffer.java - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: c3aaa11e4eb6 Author: jgodinez Date: 2009-04-20 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c3aaa11e4eb6 6821495: test/java/awt/print/PrinterJob/PrtException.java fails Reviewed-by: igor, prr ! test/java/awt/PrintJob/EdgeTest/EdgeTest.java ! test/java/awt/PrintJob/MultipleEnd/MultipleEnd.java + test/java/awt/print/PrinterJob/Collate2DPrintingTest.java + test/java/awt/print/PrinterJob/PrtException.java ! test/javax/print/CheckDupFlavor.java + test/javax/print/LookupServices.java ! test/javax/print/TestRaceCond.java + test/javax/print/attribute/Chroma.java + test/javax/print/attribute/ChromaticityValues.java + test/javax/print/attribute/GetCopiesSupported.java ! test/javax/print/attribute/PSCopiesFlavorTest.java + test/javax/print/attribute/SidesPageRangesTest.java + test/javax/print/attribute/SupportedPrintableAreas.java + test/javax/print/attribute/autosense/PrintAutoSenseData.java Changeset: 53ca5822bdfe Author: jgodinez Date: 2009-04-21 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/53ca5822bdfe 6829678: StrokeShapeTest: createStrokedShape() behaves differently Reviewed-by: igor, flar Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/Stroker.java + test/sun/pisces/StrokeShapeTest.java Changeset: b4450e6de8a3 Author: jgodinez Date: 2009-04-28 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b4450e6de8a3 Merge ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/font/TrueTypeFont.java - src/share/classes/sun/text/normalizer/UProperty.java - src/share/native/java/util/zip/ZipEntry.c - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 662a327cfe1d Author: jgodinez Date: 2009-04-29 12:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/662a327cfe1d Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: f8b061ea131c Author: jgodinez Date: 2009-05-05 09:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f8b061ea131c Merge - src/share/native/sun/java2d/pipe/RenderBuffer.c Changeset: 057e4afcf978 Author: alanb Date: 2009-04-23 19:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/057e4afcf978 6832557: TEST_BUG: java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java fails to compile Reviewed-by: darcy, mcimadamore ! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java Changeset: 164ce9ff8b58 Author: mchung Date: 2009-04-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/164ce9ff8b58 6829503: addShutdownHook fails if called after shutdown has commenced. Summary: allow shutdown hook to be added during shutdown and handle properly if it fails to add Reviewed-by: alanb, dholmes, martin ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Shutdown.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java + test/java/lang/Runtime/shutdown/ShutdownHooks.java + test/java/lang/Runtime/shutdown/ShutdownHooks.sh Changeset: d2114c1adb2d Author: sherman Date: 2009-05-01 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d2114c1adb2d 6836489: Incorrect @link usage in java.util.zip API doc Summary: correct the wrong @link tag Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java Changeset: e1a713f0361f Author: alanb Date: 2009-05-04 19:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e1a713f0361f 6834246: (ch) AsynchronousSocketChannel#write completes with wrong number of bytes written under load (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Changeset: b3720710a4ba Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b3720710a4ba Merge Changeset: d201987cb76c Author: jrose Date: 2009-05-05 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d201987cb76c 6829144: JSR 292 JVM features need a provisional Java API Summary: JDK API and runtime (partial) for anonk, meth, indy Reviewed-by: mr ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/dyn/Makefile + src/share/classes/java/dyn/CallSite.java + src/share/classes/java/dyn/InvokeDynamic.java + src/share/classes/java/dyn/InvokeDynamicBootstrapError.java + src/share/classes/java/dyn/JavaMethodHandle.java + src/share/classes/java/dyn/Linkage.java + src/share/classes/java/dyn/LinkagePermission.java + src/share/classes/java/dyn/MethodHandle.java + src/share/classes/java/dyn/MethodHandles.java + src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/MethodTypeForm.java + src/share/classes/java/dyn/NoAccessException.java + src/share/classes/java/dyn/WrongMethodTypeException.java + src/share/classes/java/dyn/package-info.java + src/share/classes/sun/dyn/Access.java + src/share/classes/sun/dyn/AdapterMethodHandle.java + src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/CallSiteImpl.java + src/share/classes/sun/dyn/DirectMethodHandle.java + src/share/classes/sun/dyn/FilterGeneric.java + src/share/classes/sun/dyn/FilterOneArgument.java + src/share/classes/sun/dyn/FromGeneric.java + src/share/classes/sun/dyn/Invokers.java + src/share/classes/sun/dyn/MemberName.java + src/share/classes/sun/dyn/MethodHandleImpl.java + src/share/classes/sun/dyn/MethodHandleNatives.java + src/share/classes/sun/dyn/MethodTypeImpl.java + src/share/classes/sun/dyn/ToGeneric.java + src/share/classes/sun/dyn/anon/AnonymousClassLoader.java + src/share/classes/sun/dyn/anon/ConstantPoolParser.java + src/share/classes/sun/dyn/anon/ConstantPoolPatch.java + src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java + src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java + src/share/classes/sun/dyn/empty/Empty.java + src/share/classes/sun/dyn/package-info.java + src/share/classes/sun/dyn/util/BytecodeName.java + src/share/classes/sun/dyn/util/BytecodeSignature.java + src/share/classes/sun/dyn/util/ValueConversions.java + src/share/classes/sun/dyn/util/VerifyAccess.java + src/share/classes/sun/dyn/util/VerifyType.java + src/share/classes/sun/dyn/util/Wrapper.java + src/share/classes/sun/dyn/util/package-info.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/javavm/export/classfile_constants.h ! src/share/native/common/check_code.c ! src/share/native/common/opcodes.in_out Changeset: 9ba256e2e5c1 Author: tbell Date: 2009-05-05 23:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9ba256e2e5c1 Merge Changeset: 878863c9072d Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/878863c9072d Added tag jdk7-b58 for changeset 9ba256e2e5c1 ! .hgtags Changeset: 2007e3d9c195 Author: anthony Date: 2009-05-05 14:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2007e3d9c195 6762511: Translucency is not working on Linux using Metacity Summary: Introduced additional blits and new X11 surface types (ARGB, ABGR) Reviewed-by: art, avu ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: ba95c9101e50 Author: art Date: 2009-05-06 12:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ba95c9101e50 6837004: java.awt.GraphicsDevice.setFullScreenWindow throws NPE for windows with background color not set Reviewed-by: yan, dcherepanov ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: b28b073e72b6 Author: anthony Date: 2009-05-06 20:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b28b073e72b6 6838046: Rollback 6762511 due to build failure (6838003) Reviewed-by: yan ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java ! src/solaris/classes/sun/java2d/x11/X11PMBlitLoops.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/native/sun/awt/X11Color.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h Changeset: 2b86dbc51d11 Author: yan Date: 2009-05-06 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2b86dbc51d11 Merge Changeset: 0c6f5f1c58fd Author: yan Date: 2009-05-12 00:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0c6f5f1c58fd Merge Changeset: 2387e3b1994e Author: jrose Date: 2009-05-11 21:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2387e3b1994e 6839802: java.dyn needs to be on the CORE_PKGS list Summary: fix makefile to expose the new APIs in the core list; edit some javadocs for correctness Reviewed-by: mr ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java Changeset: 29180ef374c8 Author: jrose Date: 2009-05-12 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/29180ef374c8 6839839: access checking logic is wrong at three points in MethodHandles Summary: point fixes to access checking logic Reviewed-by: mr ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/DirectMethodHandle.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/util/VerifyAccess.java Changeset: 2a5a1b269e89 Author: xdono Date: 2009-05-12 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2a5a1b269e89 Merge Changeset: 827a93c4d06a Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/827a93c4d06a Added tag jdk7-b59 for changeset 2a5a1b269e89 ! .hgtags From john.coomes at sun.com Thu May 14 22:58:35 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 15 May 2009 05:58:35 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 4 new changesets Message-ID: <20090515055842.EBEB1EEF6@hg.openjdk.java.net> Changeset: e2722bd43f3a Author: jrose Date: 2009-05-04 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/e2722bd43f3a 6829189: Java programming with JSR 292 needs language support Summary: Language changes documented in http://wikis.sun.com/display/mlvm/ProjectCoinProposal Reviewed-by: jjg, darcy, mcimadamore ! src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/RuntimeConstants.java + test/tools/javac/meth/InvokeDyn.java + test/tools/javac/meth/InvokeMH.java + test/tools/javac/meth/MakeNegTests.sh + test/tools/javac/quid/MakeNegTests.sh + test/tools/javac/quid/QuotedIdent.java + test/tools/javac/quid/QuotedIdent2.java Changeset: 5bcac54d408b Author: tbell Date: 2009-05-04 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/5bcac54d408b Merge Changeset: 88bcb6772159 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/88bcb6772159 Added tag jdk7-b58 for changeset 5bcac54d408b ! .hgtags Changeset: 0f653be1a42f Author: vasya Date: 2009-05-14 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/0f653be1a42f Added tag jdk7-b59 for changeset 88bcb6772159 ! .hgtags From Igor.Veresov at Sun.COM Fri May 15 23:18:24 2009 From: Igor.Veresov at Sun.COM (Igor Veresov) Date: Fri, 15 May 2009 23:18:24 -0700 Subject: Request for review(S): 6841831 G1: assert(contains_reference(from),"We just added it!") fires Message-ID: <4A0E5AB0.80103@sun.com> During parallel rset updating we have to make sure that the worker ids of the refinement threads do not intersect with the worker ids that can be claimed by the mutator threads. Webrev: http://cr.openjdk.java.net/~iveresov/6841831/webrev.00/ From igor.veresov at sun.com Mon May 18 16:41:16 2009 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Mon, 18 May 2009 23:41:16 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6841831: G1: assert(contains_reference(from), "We just added it!") fires Message-ID: <20090518234125.39866E24A@hg.openjdk.java.net> Changeset: 215f81b4d9b3 Author: iveresov Date: 2009-05-18 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/215f81b4d9b3 6841831: G1: assert(contains_reference(from),"We just added it!") fires Summary: During parallel rset updating we have to make sure that the worker ids of the refinement threads do not intersect with the worker ids that can be claimed by the mutator threads. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 From alal at hotwire.com Tue May 19 10:12:51 2009 From: alal at hotwire.com (Anuj Lal) Date: Tue, 19 May 2009 10:12:51 -0700 Subject: frequent full GC: why? Message-ID: Jdk version 1.5.0_16rev9 What can the cause of full gc back to back?. We are seeing frequent full GC even though enough space there in old space as well as in perm space ?. When new space fills up I expect only new gc but not FULL GC. Old space is only 126 MB filled ( out of 194MB) Permspace is only 129MB out of 215 ( max perm space is 256mb) These is our setting -Xms2410m -server -XX:CMSInitiatingOccupancyFraction=75 Xmx2410m -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMarkStackSize=32M -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M - -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution - 1071256.659: [Full GC {Heap before gc invocations=4293: par new generation total 449408K, used 380965K [0x4f800000, 0x6f800000, 0x6f800000) eden space 374528K, 99% used [0x4f800000, 0x66517448, 0x665c0000) from space 74880K, 9% used [0x665c0000, 0x66cb2318, 0x6aee0000) to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) concurrent mark-sweep generation total 1943552K, used 141477K [0x6f800000, 0xe6200000, 0xe6400000) concurrent-mark-sweep perm gen total 215832K, used 129513K [0xe6400000, 0xf36c6000, 0xf6400000) 1071256.661: [CMS: 141477K->126065K(1943552K), 3.9483474 secs] 522443K->126065K(2392960K), [CMS Perm : 129513K->129487K(215832K)]Heap after gc invocations=4294: par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, 0x6f800000) eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) concurrent mark-sweep generation total 1943552K, used 126065K [0x6f800000, 0xe6200000, 0xe6400000) concurrent-mark-sweep perm gen total 215832K, used 129487K [0xe6400000, 0xf36c6000, 0xf6400000) } , 3.9511002 secs] 1071289.014: [Full GC {Heap before gc invocations=4294: par new generation total 449408K, used 129843K [0x4f800000, 0x6f800000, 0x6f800000) eden space 374528K, 34% used [0x4f800000, 0x576ccd88, 0x665c0000) from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) concurrent mark-sweep generation total 1943552K, used 126065K [0x6f800000, 0xe6200000, 0xe6400000) concurrent-mark-sweep perm gen total 215832K, used 129496K [0xe6400000, 0xf36c6000, 0xf6400000) 1071289.016: [CMS[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor1251] [Unloading class sun.reflect.GeneratedMethodAccessor3111] : 126065K->123793K(1943552K), 4.6073158 secs] 255908K->123793K(2392960K), [CMS Perm : 129496K->129483K(215832K)]Heap after gc invocations=4295: par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, 0x6f800000) eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) concurrent mark-sweep generation total 1943552K, used 123793K [0x6f800000, 0xe6200000, 0xe6400000) concurrent-mark-sweep perm gen total 215832K, used 129483K [0xe6400000, 0xf36c6000, 0xf6400000) } , 4.6100803 secs] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090519/0ea2862d/attachment.html From Y.S.Ramakrishna at Sun.COM Tue May 19 11:15:10 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 19 May 2009 11:15:10 -0700 Subject: Strange long ParNew collections In-Reply-To: <4A1297AC.5060205@mag.se> References: <4A017D35.7000208@mag.se> <4A02078C.4080904@Sun.COM> <4A1297AC.5060205@mag.se> Message-ID: <4A12F72E.2000906@Sun.COM> Yes, from your description, it's very likely you are running into the bug that was fixed in CR 6786503. The fix is available in 1.5u19 (and 6u14 and open jdk 7). Your Sun support can confirm that this is indeed the bug if you send them a series of pstacks taken during the "hang" (i suppose you would need to have your watchdog get the gcore/pstack before restarting the prcoess since the onset of the bug is somewhat unpredictable and you can't be waiting for the event before your watchdog restarts the process; or you can turn off your watchdog if in a test environment and collect the pstacks manually, since the "hang" usually lasts for a while, even if you have gone out for a cup of coffee :-). -- ramki On 05/19/09 04:27, Kaj Nygren wrote: > Hi, > > Thanks for your help. I wanted to give an update and have a couple of > more questions :) > > We did change to -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=4 and now > the ParNew collections are working a lot better. We have also turned off > incremental mode as Jon suggested. > > Now we do have one problem left though, it seems that the CMS-GC gets > stuck sometimes during parallell rescan. The output looks like this: > > 24004,062: [CMS-concurrent-sweep: 1,755/1,932 secs] > 24004,062: [CMS-concurrent-reset-start] > 24004,163: [CMS-concurrent-reset: 0,101/0,101 secs] > 24006,163: [GC [1 CMS-initial-mark: 10348978K(18432000K)] > 10521837K(19353600K), 0,1055176 secs] > 24006,269: [CMS-concurrent-mark-start] > 24010,642: [CMS-concurrent-mark: 4,373/4,373 secs] > 24010,642: [CMS-concurrent-preclean-start] > 24010,730: [CMS-concurrent-preclean: 0,085/0,088 secs] > 24010,730: [CMS-concurrent-abortable-preclean-start] > CMS: abort preclean due to time 24011,824: > [CMS-concurrent-abortable-preclean: 0,792/1,094 secs] > 24011,828: [GC[YG occupancy: 332774 K (921600 K)] > 24011,829: [Rescan (parallel) > > Then the JVM hangs for more than 5 minutes at which time our watchdog > determines that the server is hung and restarts it. It did happen with > iCMS and apparently it still happens using CMS. > > I searched around and found one similar report: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2009-January/000327.html > > I know this is just a guess, but could we be experiencing the same bug? > If so, am I correct in interpreting the bug-reports that it should be > fixed in 1.5.0_18? (we are running 1.5.0_16 at the moment). > > /Kaj > > Y.S.Ramakrishna at Sun.COM skrev: >> This may or may not be a cause of the sudden spikes in >> ParNew collection, but I'd suggest using the survivor >> spaces to age objects for at least a few collections >> before promoting to the old gen. This reduces pressure >> on the old gen allocation (during scavenge) improving >> scavenges and on CMS collection as well. >> >> I'd suggest trying -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=4 >> to start off with and iterate based on data from >> -XX:+PrintTenuringDistribution. >> >> It is possible that the promotion of very short-lived objects fragments >> the old gen and causes old gen allocation (for promotion) to slow down. >> It can also cause lots of mutation in the old gen and adversely affect >> card-scanning times further slowing down scavenges. >> >> -- ramki >> >> On 05/06/09 05:06, Kaj Nygren wrote: >>> Hi, >>> >>> We are having problems with occational long ParNew pauses in our >>> application running on a Jboss server. The server runs well for most >>> of the time but sometimes we get ParNew collections that can take up >>> to 120 seconds. Most of the time we have several consecutive slow >>> collections, which are more or less killing the server under high load. >>> >>> We are using JDK 1.5.0_16 on Windows Server 2003, and are using >>> ParNew + Concurrent CMS. >>> >>> Our GC configuration is: >>> >>> wrapper.java.additional.1=-Dprogram.name=run.bat >>> wrapper.java.additional.2=-server >>> wrapper.java.additional.3=-Xms19000m >>> wrapper.java.additional.4=-Xmx19000m >>> wrapper.java.additional.5="-XX:NewSize=1000m" >>> wrapper.java.additional.6="-XX:MaxNewSize=1000m" >>> wrapper.java.additional.7="-XX:MaxPermSize=256m" >>> wrapper.java.additional.8="-XX:PermSize=256m" >>> wrapper.java.additional.11="-Xloggc:c:\mygclog.gc" >>> wrapper.java.additional.12="-XX:+UseConcMarkSweepGC" >>> wrapper.java.additional.13="-XX:+PrintGCDetails" >>> wrapper.java.additional.14="-XX:-PrintTenuringDistribution" >>> wrapper.java.additional.15="-XX:+PrintHeapAtGC" >>> wrapper.java.additional.16="-XX:+DisableExplicitGC" >>> wrapper.java.additional.17="-XX:+PrintGCTimeStamps" >>> wrapper.java.additional.18="-XX:CMSInitiatingOccupancyFraction=50" >>> wrapper.java.additional.19="-XX:+CMSIncrementalMode" >>> wrapper.java.additional.20="-XX:+CMSIncrementalPacing" >>> wrapper.java.additional.21="-verbose:gc" >>> >>> Usually ParNew is quick as can be seen here: >>> >>> 614276,653: [ParNew: 935058K->0K(1023040K), 0,0624699 secs] >>> 12383872K->11459948K(19455040K) icms_dc=22 Heap after gc >>> invocations=57822: >>> par new generation total 1023040K, used 0K [0x000000007fff0000, >>> 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, >>> 0x000000007fff0000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> concurrent mark-sweep generation total 18432000K, used 11459948K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112069K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> } >>> , 0,0628860 secs] >>> >>> But suddenly it becomes really slow: >>> >>> 620659,717: [ParNew: 1022080K->0K(1023040K), 1,3313817 secs] >>> 12688913K->11692925K(19455040K) icms_dc=10 Heap after gc >>> invocations=58587: >>> par new generation total 1023040K, used 0K [0x000000007fff0000, >>> 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, >>> 0x000000007fff0000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> concurrent mark-sweep generation total 18432000K, used 11692925K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112098K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> } >>> , 1,3319554 secs] >>> 620663,221: [GC {Heap before gc invocations=58587: >>> par new generation total 1023040K, used 1022080K >>> [0x000000007fff0000, 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 100% used [0x000000007fff0000, >>> 0x00000000be610000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> concurrent mark-sweep generation total 18432000K, used 11692925K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112106K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> 620663,222: [ParNew: 1022080K->0K(1023040K), 10,2909893 secs] >>> 12715005K->11936864K(19455040K) icms_dc=10 Heap after gc >>> invocations=58588: >>> par new generation total 1023040K, used 0K [0x000000007fff0000, >>> 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, >>> 0x000000007fff0000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> concurrent mark-sweep generation total 18432000K, used 11936864K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112106K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> } >>> , 10,2915548 secs] >>> 620676,392: [GC {Heap before gc invocations=58588: >>> par new generation total 1023040K, used 1022080K >>> [0x000000007fff0000, 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 100% used [0x000000007fff0000, >>> 0x00000000be610000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> concurrent mark-sweep generation total 18432000K, used 11936864K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112106K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> 620676,392: [ParNew: 1022080K->0K(1023040K), 3,8905950 secs] >>> 12958944K->12020225K(19455040K) icms_dc=10 Heap after gc >>> invocations=58589: >>> par new generation total 1023040K, used 0K [0x000000007fff0000, >>> 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, >>> 0x000000007fff0000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> concurrent mark-sweep generation total 18432000K, used 12020225K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112106K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> } >>> , 3,8911113 secs] >>> 620682,667: [GC {Heap before gc invocations=58589: >>> par new generation total 1023040K, used 1022080K >>> [0x000000007fff0000, 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 100% used [0x000000007fff0000, >>> 0x00000000be610000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> to space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> concurrent mark-sweep generation total 18432000K, used 12020225K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112112K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> 620682,668: [ParNew: 1022080K->0K(1023040K), 9,4186088 secs] >>> 13042305K->12214571K(19455040K) icms_dc=10 Heap after gc >>> invocations=58590: >>> par new generation total 1023040K, used 0K [0x000000007fff0000, >>> 0x00000000be7f0000, 0x00000000be7f0000) >>> eden space 1022080K, 0% used [0x000000007fff0000, >>> 0x000000007fff0000, 0x00000000be610000) >>> from space 960K, 0% used [0x00000000be700000, 0x00000000be700000, >>> 0x00000000be7f0000) >>> to space 960K, 0% used [0x00000000be610000, 0x00000000be610000, >>> 0x00000000be700000) >>> concurrent mark-sweep generation total 18432000K, used 12214571K >>> [0x00000000be7f0000, 0x00000005237f0000, 0x00000005237f0000) >>> concurrent-mark-sweep perm gen total 262144K, used 112112K >>> [0x00000005237f0000, 0x00000005337f0000, 0x00000005337f0000) >>> } >>> , 9,4191551 secs] >>> >>> We also have problems with occational promotion failed, which I >>> assume is due to fragmentation. >>> I have attatched a longer log, which shows this behaviour and ends >>> with a promotion failed. >>> >>> Does anybody have a glue as to what is going wrong, and how we can >>> change our gc configuration to reduce the problems? >>> Any help is greatly appreciated! >>> >>> Regards >>> >>> Kaj Nygren >>> kaj at mag.se >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Y.S.Ramakrishna at Sun.COM Tue May 19 11:19:48 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 19 May 2009 11:19:48 -0700 Subject: frequent full GC: why? In-Reply-To: References: Message-ID: <4A12F844.6050509@Sun.COM> Please add -XX:+DisableExplicitGC just in case, unbeknownst to you, some third-party library (or the jdk libraries) are calling system gc. -- ramki On 05/19/09 10:12, Anuj Lal wrote: > > > Jdk version 1.5.0_16rev9 > > What can the cause of full gc back to back?. > > We are seeing frequent full GC even though enough space there in old > space as well as in perm space ?. > > When new space fills up I expect only new gc but not FULL GC. > > > > Old space is only 126 MB filled ( out of 194MB) > > Permspace is only 129MB out of 215 ( max perm space is 256mb) > > > > These is our setting > > -Xms2410m -server -XX:CMSInitiatingOccupancyFraction=75 Xmx2410m > -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 > -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M > -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps > -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC > -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection > -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMarkStackSize=32M > -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M - > -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC > -XX:+PrintTenuringDistribution ? > > > > > > 1071256.659: [Full GC {Heap before gc invocations=4293: > > par new generation total 449408K, used 380965K [0x4f800000, > 0x6f800000, 0x6f800000) > > eden space 374528K, 99% used [0x4f800000, 0x66517448, 0x665c0000) > > from space 74880K, 9% used [0x665c0000, 0x66cb2318, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 141477K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129513K [0xe6400000, > 0xf36c6000, 0xf6400000) > > 1071256.661: [CMS: 141477K->126065K(1943552K), 3.9483474 secs] > 522443K->126065K(2392960K), [CMS Perm : 129513K->129487K(215832K)]Heap > after gc invocations=4294: > > par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, > 0x6f800000) > > eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 126065K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129487K [0xe6400000, > 0xf36c6000, 0xf6400000) > > } > > , 3.9511002 secs] > > 1071289.014: [Full GC {Heap before gc invocations=4294: > > par new generation total 449408K, used 129843K [0x4f800000, > 0x6f800000, 0x6f800000) > > eden space 374528K, 34% used [0x4f800000, 0x576ccd88, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 126065K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129496K [0xe6400000, > 0xf36c6000, 0xf6400000) > > 1071289.016: [CMS[Unloading class > sun.reflect.GeneratedSerializationConstructorAccessor1251] > > [Unloading class sun.reflect.GeneratedMethodAccessor3111] > > : 126065K->123793K(1943552K), 4.6073158 secs] > 255908K->123793K(2392960K), [CMS Perm : 129496K->129483K(215832K)]Heap > after gc invocations=4295: > > par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, > 0x6f800000) > > eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 123793K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129483K [0xe6400000, > 0xf36c6000, 0xf6400000) > > } > > , 4.6100803 secs] > From Jon.Masamitsu at Sun.COM Tue May 19 11:24:42 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 19 May 2009 11:24:42 -0700 Subject: frequent full GC: why? In-Reply-To: References: Message-ID: <4A12F96A.9000600@Sun.COM> This alias is concerned primarily with the openjdk source base. jdk5 is rather old and lots has changed since then so you might have better luck asking through your Sun support contact. On 05/19/09 10:12, Anuj Lal wrote: > > > Jdk version 1.5.0_16rev9 > > What can the cause of full gc back to back?. > > We are seeing frequent full GC even though enough space there in old > space as well as in perm space ?. > > When new space fills up I expect only new gc but not FULL GC. > > > > Old space is only 126 MB filled ( out of 194MB) > > Permspace is only 129MB out of 215 ( max perm space is 256mb) > > > > These is our setting > > -Xms2410m -server -XX:CMSInitiatingOccupancyFraction=75 Xmx2410m > -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 > -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M > -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps > -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC > -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection > -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMarkStackSize=32M > -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M - > -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC > -XX:+PrintTenuringDistribution ? > > > > > > 1071256.659: [Full GC {Heap before gc invocations=4293: > > par new generation total 449408K, used 380965K [0x4f800000, > 0x6f800000, 0x6f800000) > > eden space 374528K, 99% used [0x4f800000, 0x66517448, 0x665c0000) > > from space 74880K, 9% used [0x665c0000, 0x66cb2318, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 141477K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129513K [0xe6400000, > 0xf36c6000, 0xf6400000) > > 1071256.661: [CMS: 141477K->126065K(1943552K), 3.9483474 secs] > 522443K->126065K(2392960K), [CMS Perm : 129513K->129487K(215832K)]Heap > after gc invocations=4294: > > par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, > 0x6f800000) > > eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 126065K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129487K [0xe6400000, > 0xf36c6000, 0xf6400000) > > } > > , 3.9511002 secs] > > 1071289.014: [Full GC {Heap before gc invocations=4294: > > par new generation total 449408K, used 129843K [0x4f800000, > 0x6f800000, 0x6f800000) > > eden space 374528K, 34% used [0x4f800000, 0x576ccd88, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 126065K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129496K [0xe6400000, > 0xf36c6000, 0xf6400000) > > 1071289.016: [CMS[Unloading class > sun.reflect.GeneratedSerializationConstructorAccessor1251] > > [Unloading class sun.reflect.GeneratedMethodAccessor3111] > > : 126065K->123793K(1943552K), 4.6073158 secs] > 255908K->123793K(2392960K), [CMS Perm : 129496K->129483K(215832K)]Heap > after gc invocations=4295: > > par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, > 0x6f800000) > > eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 123793K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129483K [0xe6400000, > 0xf36c6000, 0xf6400000) > > } > > , 4.6100803 secs] > From alal at hotwire.com Tue May 19 11:36:58 2009 From: alal at hotwire.com (Anuj Lal) Date: Tue, 19 May 2009 11:36:58 -0700 Subject: frequent full GC: why? In-Reply-To: <4A12F844.6050509@Sun.COM> References: <4A12F844.6050509@Sun.COM> Message-ID: We purposefully not adding -XX:+DisableExplicitGC as we do force full gc during night time so that compaction of old space can happen. Any other reason why this may be happening? Alal -----Original Message----- From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM] Sent: Tuesday, May 19, 2009 11:20 AM To: Anuj Lal Cc: hotspot-gc-dev at openjdk.java.net Subject: Re: frequent full GC: why? Please add -XX:+DisableExplicitGC just in case, unbeknownst to you, some third-party library (or the jdk libraries) are calling system gc. -- ramki On 05/19/09 10:12, Anuj Lal wrote: > > > Jdk version 1.5.0_16rev9 > > What can the cause of full gc back to back?. > > We are seeing frequent full GC even though enough space there in old > space as well as in perm space ?. > > When new space fills up I expect only new gc but not FULL GC. > > > > Old space is only 126 MB filled ( out of 194MB) > > Permspace is only 129MB out of 215 ( max perm space is 256mb) > > > > These is our setting > > -Xms2410m -server -XX:CMSInitiatingOccupancyFraction=75 Xmx2410m > -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 > -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M > -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps > -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC > -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection > -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMarkStackSize=32M > -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M - > -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC > -XX:+PrintTenuringDistribution - > > > > > > 1071256.659: [Full GC {Heap before gc invocations=4293: > > par new generation total 449408K, used 380965K [0x4f800000, > 0x6f800000, 0x6f800000) > > eden space 374528K, 99% used [0x4f800000, 0x66517448, 0x665c0000) > > from space 74880K, 9% used [0x665c0000, 0x66cb2318, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 141477K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129513K [0xe6400000, > 0xf36c6000, 0xf6400000) > > 1071256.661: [CMS: 141477K->126065K(1943552K), 3.9483474 secs] > 522443K->126065K(2392960K), [CMS Perm : 129513K->129487K(215832K)]Heap > after gc invocations=4294: > > par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, > 0x6f800000) > > eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 126065K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129487K [0xe6400000, > 0xf36c6000, 0xf6400000) > > } > > , 3.9511002 secs] > > 1071289.014: [Full GC {Heap before gc invocations=4294: > > par new generation total 449408K, used 129843K [0x4f800000, > 0x6f800000, 0x6f800000) > > eden space 374528K, 34% used [0x4f800000, 0x576ccd88, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 126065K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129496K [0xe6400000, > 0xf36c6000, 0xf6400000) > > 1071289.016: [CMS[Unloading class > sun.reflect.GeneratedSerializationConstructorAccessor1251] > > [Unloading class sun.reflect.GeneratedMethodAccessor3111] > > : 126065K->123793K(1943552K), 4.6073158 secs] > 255908K->123793K(2392960K), [CMS Perm : 129496K->129483K(215832K)]Heap > after gc invocations=4295: > > par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, > 0x6f800000) > > eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) > > from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) > > to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) > > concurrent mark-sweep generation total 1943552K, used 123793K > [0x6f800000, 0xe6200000, 0xe6400000) > > concurrent-mark-sweep perm gen total 215832K, used 129483K [0xe6400000, > 0xf36c6000, 0xf6400000) > > } > > , 4.6100803 secs] > From Y.S.Ramakrishna at Sun.COM Tue May 19 11:56:47 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 19 May 2009 11:56:47 -0700 Subject: frequent full GC: why? In-Reply-To: References: <4A12F844.6050509@Sun.COM> Message-ID: <4A1300EF.1090505@Sun.COM> Not that I can think of. As Jon indicated, contacting your Sun support may yield more avenues for investigation. -- ramki On 05/19/09 11:36, Anuj Lal wrote: > We purposefully not adding -XX:+DisableExplicitGC as we do force full gc during night time so that compaction of old space can happen. > > Any other reason why this may be happening? > > Alal > > -----Original Message----- > From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM] > Sent: Tuesday, May 19, 2009 11:20 AM > To: Anuj Lal > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: frequent full GC: why? > > Please add -XX:+DisableExplicitGC just in case, unbeknownst to you, > some third-party library (or the jdk libraries) are calling system gc. > > -- ramki > > On 05/19/09 10:12, Anuj Lal wrote: >> >> Jdk version 1.5.0_16rev9 >> >> What can the cause of full gc back to back?. >> >> We are seeing frequent full GC even though enough space there in old >> space as well as in perm space ?. >> >> When new space fills up I expect only new gc but not FULL GC. >> >> >> >> Old space is only 126 MB filled ( out of 194MB) >> >> Permspace is only 129MB out of 215 ( max perm space is 256mb) >> >> >> >> These is our setting >> >> -Xms2410m -server -XX:CMSInitiatingOccupancyFraction=75 Xmx2410m >> -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 >> -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M >> -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps >> -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC >> -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection >> -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure >> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMarkStackSize=32M >> -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M - >> -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC >> -XX:+PrintTenuringDistribution - >> >> >> >> >> >> 1071256.659: [Full GC {Heap before gc invocations=4293: >> >> par new generation total 449408K, used 380965K [0x4f800000, >> 0x6f800000, 0x6f800000) >> >> eden space 374528K, 99% used [0x4f800000, 0x66517448, 0x665c0000) >> >> from space 74880K, 9% used [0x665c0000, 0x66cb2318, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 141477K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129513K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> 1071256.661: [CMS: 141477K->126065K(1943552K), 3.9483474 secs] >> 522443K->126065K(2392960K), [CMS Perm : 129513K->129487K(215832K)]Heap >> after gc invocations=4294: >> >> par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, >> 0x6f800000) >> >> eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) >> >> from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 126065K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129487K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> } >> >> , 3.9511002 secs] >> >> 1071289.014: [Full GC {Heap before gc invocations=4294: >> >> par new generation total 449408K, used 129843K [0x4f800000, >> 0x6f800000, 0x6f800000) >> >> eden space 374528K, 34% used [0x4f800000, 0x576ccd88, 0x665c0000) >> >> from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 126065K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129496K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> 1071289.016: [CMS[Unloading class >> sun.reflect.GeneratedSerializationConstructorAccessor1251] >> >> [Unloading class sun.reflect.GeneratedMethodAccessor3111] >> >> : 126065K->123793K(1943552K), 4.6073158 secs] >> 255908K->123793K(2392960K), [CMS Perm : 129496K->129483K(215832K)]Heap >> after gc invocations=4295: >> >> par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, >> 0x6f800000) >> >> eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) >> >> from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 123793K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129483K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> } >> >> , 4.6100803 secs] >> > From Y.S.Ramakrishna at Sun.COM Tue May 19 15:33:20 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 19 May 2009 15:33:20 -0700 Subject: frequent full GC: why? In-Reply-To: References: <4A12F844.6050509@Sun.COM> Message-ID: <4A1333B0.1020003@Sun.COM> I vaguely recall someone on this list pointing out a hack to work around that apparent Catch-22. I think they said they used to run with -XX:+DisableExplicitGC and at night when they wanted to do a compacting collection they'd run: % jmap -histo:live to force their JVM to compact the heap. You'll probably find the exchange in the archives for this list. However, of course, the compacting side-effect of jmap may or may not be present in a future JVM (besides, I do not recall whether this will work with older jvm's). -- ramki On 05/19/09 11:36, Anuj Lal wrote: > We purposefully not adding -XX:+DisableExplicitGC as we do force full gc during night time so that compaction of old space can happen. > > Any other reason why this may be happening? > > Alal > > -----Original Message----- > From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM] > Sent: Tuesday, May 19, 2009 11:20 AM > To: Anuj Lal > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: frequent full GC: why? > > Please add -XX:+DisableExplicitGC just in case, unbeknownst to you, > some third-party library (or the jdk libraries) are calling system gc. > > -- ramki > > On 05/19/09 10:12, Anuj Lal wrote: >> >> Jdk version 1.5.0_16rev9 >> >> What can the cause of full gc back to back?. >> >> We are seeing frequent full GC even though enough space there in old >> space as well as in perm space ?. >> >> When new space fills up I expect only new gc but not FULL GC. >> >> >> >> Old space is only 126 MB filled ( out of 194MB) >> >> Permspace is only 129MB out of 215 ( max perm space is 256mb) >> >> >> >> These is our setting >> >> -Xms2410m -server -XX:CMSInitiatingOccupancyFraction=75 Xmx2410m >> -XX:NewSize=512M -XX:MaxNewSize=512M -XX:MaxTenuringThreshold=6 >> -XX:SurvivorRatio=5 -XX:TargetSurvivorRatio=80 -XX:MaxPermSize=256M >> -XX:ThreadStackSize=256 -verbose:gc -XX:+PrintGCTimeStamps >> -XX:+PrintClassHistogram -XX:+UseConcMarkSweepGC -XX:+UseParNewGC >> -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection >> -XX:CMSFullGCsBeforeCompaction=0 -XX:+HandlePromotionFailure >> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMarkStackSize=32M >> -XX:CodeCacheMinimumFreeSpace=2M -XX:ReservedCodeCacheSize=64M - >> -XX:CMSMaxAbortablePrecleanTime=1 -XX:+PrintGCDetails -XX:+PrintHeapAtGC >> -XX:+PrintTenuringDistribution - >> >> >> >> >> >> 1071256.659: [Full GC {Heap before gc invocations=4293: >> >> par new generation total 449408K, used 380965K [0x4f800000, >> 0x6f800000, 0x6f800000) >> >> eden space 374528K, 99% used [0x4f800000, 0x66517448, 0x665c0000) >> >> from space 74880K, 9% used [0x665c0000, 0x66cb2318, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 141477K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129513K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> 1071256.661: [CMS: 141477K->126065K(1943552K), 3.9483474 secs] >> 522443K->126065K(2392960K), [CMS Perm : 129513K->129487K(215832K)]Heap >> after gc invocations=4294: >> >> par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, >> 0x6f800000) >> >> eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) >> >> from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 126065K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129487K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> } >> >> , 3.9511002 secs] >> >> 1071289.014: [Full GC {Heap before gc invocations=4294: >> >> par new generation total 449408K, used 129843K [0x4f800000, >> 0x6f800000, 0x6f800000) >> >> eden space 374528K, 34% used [0x4f800000, 0x576ccd88, 0x665c0000) >> >> from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 126065K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129496K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> 1071289.016: [CMS[Unloading class >> sun.reflect.GeneratedSerializationConstructorAccessor1251] >> >> [Unloading class sun.reflect.GeneratedMethodAccessor3111] >> >> : 126065K->123793K(1943552K), 4.6073158 secs] >> 255908K->123793K(2392960K), [CMS Perm : 129496K->129483K(215832K)]Heap >> after gc invocations=4295: >> >> par new generation total 449408K, used 0K [0x4f800000, 0x6f800000, >> 0x6f800000) >> >> eden space 374528K, 0% used [0x4f800000, 0x4f800000, 0x665c0000) >> >> from space 74880K, 0% used [0x665c0000, 0x665c0000, 0x6aee0000) >> >> to space 74880K, 0% used [0x6aee0000, 0x6aee0000, 0x6f800000) >> >> concurrent mark-sweep generation total 1943552K, used 123793K >> [0x6f800000, 0xe6200000, 0xe6400000) >> >> concurrent-mark-sweep perm gen total 215832K, used 129483K [0xe6400000, >> 0xf36c6000, 0xf6400000) >> >> } >> >> , 4.6100803 secs] >> > From andrey.petrusenko at sun.com Wed May 20 04:33:33 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Wed, 20 May 2009 11:33:33 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6819065: G1: eliminate high serial card table clearing time Message-ID: <20090520113335.025EDE518@hg.openjdk.java.net> Changeset: 29e7d79232b9 Author: apetrusenko Date: 2009-05-19 04:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/29e7d79232b9 6819065: G1: eliminate high serial card table clearing time Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp From spsneo at gmail.com Wed May 20 04:47:41 2009 From: spsneo at gmail.com (Siddharth Prakash Singh) Date: Wed, 20 May 2009 17:17:41 +0530 Subject: write barrier Message-ID: Hello devs, I am currently doing a project on garbage collection in multicore kernels. I will be using hotspot jvm gc to prove the results. Is there any documentation available for hotspot gc? Anticipating a reply Siddharth From Jon.Masamitsu at Sun.COM Wed May 20 06:44:14 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 20 May 2009 06:44:14 -0700 Subject: write barrier In-Reply-To: References: Message-ID: <4A14092E.5000409@Sun.COM> http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf On 05/20/09 04:47, Siddharth Prakash Singh wrote: > Hello devs, > > I am currently doing a project on garbage collection in multicore > kernels. I will be using hotspot jvm gc to prove the results. Is there > any documentation available for hotspot gc? > > Anticipating a reply > Siddharth From George.Porter at Sun.COM Wed May 20 16:33:21 2009 From: George.Porter at Sun.COM (George Porter) Date: Wed, 20 May 2009 16:33:21 -0700 Subject: Question about GC and network throughput problems Message-ID: <5AC02859-1C62-4FE0-8C50-B9678548EF94@Sun.COM> Hello everyone, I'm writing with a question on behalf of the Apache HBase project, which is an open-source implementation of Google's BigTable system, written in 100% Java. One of the developers ran into the following problem, and I wasn't sure where to look, and so I was hoping that someone on this list might have some pointers or suggestions that I could try. Thank you in advance for your time, George "I was wondering if you could help us out w/ some issues we're having performance-wise. The areas we need to look at next are rpc and the garbage collector. The rpc we can handle ourselves. I was wondering if you could point us at someone who could help with the latter. Maybe you know some java GC expert who is up to the challenge? GC pauses hamper upload rates -- halving or quartering over time -- and pauses mid-fetch bring our overall fetching throughput down as well as latency. Some time has been spent messing w/ GC options, using different engines and different tunings to some effect (so far, we're seeing one engine to upload but need another to serve), but we're not expert and we're supposed to be a 'general-use' application fielding uploads and serving concurrently." They are using Java 1.6.0_14 running on Linux x86_64. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at sun.com Tue May 26 20:32:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 27 May 2009 03:32:04 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 10 new changesets Message-ID: <20090527033223.CC6D0EA5C@hg.openjdk.java.net> Changeset: 622212a69394 Author: iveresov Date: 2009-05-08 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/622212a69394 6838842: NUMA allocator: Segfault during startup on Linux Summary: Restored os::free_memory() semantics Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp Changeset: cf71f149d7ae Author: iveresov Date: 2009-05-12 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cf71f149d7ae 6840196: NUMA allocator: crash in fastdebug during startup on Linux Summary: With libnuma >1.2 explicity use 1.1 symbols Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 53d9bf689e80 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/53d9bf689e80 Added tag jdk7-b57 for changeset f4cbf78110c7 ! .hgtags Changeset: 8078631685e4 Author: trims Date: 2009-05-07 21:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8078631685e4 Merge - make/jprt.config Changeset: fede134842ab Author: trims Date: 2009-05-07 21:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fede134842ab 6838819: Bump the HS16 build number to 03 Summary: Update the HS16 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7e1dbef51011 Author: trims Date: 2009-05-08 19:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7e1dbef51011 Merge Changeset: 07c1c01e0315 Author: trims Date: 2009-05-13 08:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/07c1c01e0315 Merge Changeset: 313b56165de7 Author: vasya Date: 2009-05-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/313b56165de7 Added tag jdk7-b58 for changeset 53d9bf689e80 ! .hgtags Changeset: c55be0c7bd32 Author: trims Date: 2009-05-13 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c55be0c7bd32 Merge Changeset: 7fd05714f579 Author: jcoomes Date: 2009-05-26 16:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7fd05714f579 Merge