May 2009 - hotspot-gc-dev

hg: jdk7/hotspot-gc/jaxws: 4 new changesets
by john.coomes＠sun.com 15 May '09

15 May '09

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

1 0

hg: jdk7/hotspot-gc/jaxp: 4 new changesets
by john.coomes＠sun.com 15 May '09

15 May '09

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

1 0

hg: jdk7/hotspot-gc/corba: 4 new changesets
by john.coomes＠sun.com 15 May '09

15 May '09

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

1 0

hg: jdk7/hotspot-gc: 2 new changesets
by john.coomes＠sun.com 15 May '09

15 May '09

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

1 0

hg: jdk7/hotspot-gc/hotspot: 6484957: G1: parallel concurrent refinement; ...
by igor.veresov＠sun.com 12 May '09

12 May '09

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

1 0

Info wanted on GC algorithms
by Dan Hicks 10 May '09

10 May '09

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

3 2

Request for review(XXS): 6838842 NUMA allocator: Segfault during startup on Linux
by Igor Veresov 08 May '09

08 May '09

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

1 0

hg: jdk7/hotspot-gc/hotspot: 5 new changesets
by john.coomes＠sun.com 08 May '09

08 May '09

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

1 0

hg: jdk7/hotspot-gc/hotspot: 3 new changesets
by john.coomes＠sun.com 08 May '09

08 May '09

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

1 0

Re: Strange long ParNew collections
by Jon Masamitsu 07 May '09

07 May '09

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(a)mag.se >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>hotspot-gc-use mailing list >>>hotspot-gc-use(a)openjdk.java.net >>>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>> >>> >>> >>_______________________________________________ >>hotspot-gc-use mailing list >>hotspot-gc-use(a)openjdk.java.net >>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> >> > >_______________________________________________ >hotspot-gc-use mailing list >hotspot-gc-use(a)openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0