From jon.masamitsu at oracle.com Thu Apr 1 09:02:44 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 01 Apr 2010 09:02:44 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: References: <4B9E8499.8030904@sun.com> <4BA0087A.2040006@Sun.COM> <4BA3AE88.3090002@sun.com> <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> Message-ID: <4BB4C3A4.40701@oracle.com> On 03/31/10 11:26, Hiroshi Yamauchi wrote: > > > ... > > I think we agree that it's a good idea to try to shrink the heap in > response to System.gc() in such a scenario/app. Yes on the shrinking on a System.gc() and perhaps for symmetry also expanding a small heap to MinFreeHeapRatio? UseAdaptiveSizePolicy will shrink the heap down during periods of low activity and it might be useful to swiftly expand the heap on a System.gc(). > > Since we are talking about a setting where the free ratio flags takes > precedence over the psAdaptiveSizePolicy's throughput goals, the > suggested logic in the original webrev is perhaps not so terrible? If > so, I suppose the logic for UseFreeRatioOnlyInSystemGCForParallelGC > does help with that because it can shrink the heap regardless of the > throughput goal. It may make sense to remove UseFreeRatioForParallelGC > and keep UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like > to see it happen inside psAdaptiveSizePolicy instead, the current > webrev does not work. > I like the structure of the original webrev with regard to the logic for using FreeRation. It's simpler than embedding it in the PSAdaptivesizePolicy. 243 if (UseFreeRatioOnlyInSystemGCForParallelGC && 245 gc_cause == GCCause::_java_lang_system_gc)) { compute_new_size(); <<<<<<<< generalization of <<<<<<<< try_to_shrink_by_free_ratio() 248 } else { use current UseAdaptiveSizePolicy } From dawn2004 at gmail.com Thu Apr 1 10:08:40 2010 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Thu, 1 Apr 2010 10:08:40 -0700 (PDT) Subject: How to monitor heap access from native threads Message-ID: <28111314.post@talk.nabble.com> Dear all, I wanna monitor all the heap access from native threads. Native threads can access JVM heap in two ways: 1. through JNI function. this will be easier to monitor, and we can instrument the jni function to record the access. 2. Native threads can also get a raw pointer to an objects, then they can access the heap through the raw pointer. For this case, I don't know how to capture and record them. Can anyone give some idea to monitor the memory access from native threads? Any third-party tools I can leverage? Thanks. Colin -- View this message in context: http://old.nabble.com/How-to-monitor-heap-access-from-native-threads-tp28111314p28111314.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From tom.rodriguez at oracle.com Fri Apr 2 11:12:32 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Apr 2010 11:12:32 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <1270211955.23285.8.camel@macbook> References: <1270211955.23285.8.camel@macbook> Message-ID: That looks good. We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods. Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived. I don't know if there's any easy way to do that. tom On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ > > 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations > Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. > Reviewed-by: > > During testing of JSR 292's SPARC C2 port I found a couple of crashes > which came from unfixed code-embedded oops. > > This can be triggered with ScavengeRootsInCode={1,2}. > > The fix is to call fix_oop_relocations in > CodeCache::scavenge_root_nmethods_do after oops may have been updated. > > src/share/vm/code/codeCache.cpp > > From y.s.ramakrishna at oracle.com Fri Apr 2 11:45:26 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 02 Apr 2010 11:45:26 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: References: <1270211955.23285.8.camel@macbook> Message-ID: <4BB63B46.7080900@oracle.com> Ah, good point. Yes this should be possible without too much trouble [1] (both the automatic promotion and/or the pruning) because the scavangable nmethods list seems to be processed as a separate root-set, so we can for example send it a special "always promote" scanner and/or tell the scanner to drop nmethods that (no longer) have any young refs, the latter kinda like we do for card scanning. Christian or Tom, could one of you please open a CR to track this work so it isn't forgotten? thanks. -- ramki [1] famous last words? On 04/02/10 11:12, Tom Rodriguez wrote: > That looks good. We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods. Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived. I don't know if there's any easy way to do that. > > tom > > On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ >> >> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations >> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. >> Reviewed-by: >> >> During testing of JSR 292's SPARC C2 port I found a couple of crashes >> which came from unfixed code-embedded oops. >> >> This can be triggered with ScavengeRootsInCode={1,2}. >> >> The fix is to call fix_oop_relocations in >> CodeCache::scavenge_root_nmethods_do after oops may have been updated. >> >> src/share/vm/code/codeCache.cpp >> >> > From antonios.printezis at sun.com Fri Apr 2 12:01:06 2010 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Fri, 02 Apr 2010 19:01:06 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 20 new changesets Message-ID: <20100402190303.531EE44E8A@hg.openjdk.java.net> Changeset: 4b58861a3570 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4b58861a3570 Added tag jdk7-b86 for changeset bf823ef06b4f ! .hgtags Changeset: 07226e9eab8f Author: trims Date: 2010-03-18 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/07226e9eab8f 6936366: Fork HS17 to HS18 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS18 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3deb84ecd19d Author: trims Date: 2010-03-23 20:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3deb84ecd19d Added tag hs18-b01 for changeset 07226e9eab8f ! .hgtags Changeset: e7e7e36ccdb5 Author: trims Date: 2010-03-23 20:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e7e7e36ccdb5 Merge ! .hgtags Changeset: 465c39e1fb46 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/465c39e1fb46 Added tag jdk7-b87 for changeset e7e7e36ccdb5 ! .hgtags Changeset: 5c9df1575c39 Author: trims Date: 2010-04-01 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5c9df1575c39 Merge Changeset: 096b18156d91 Author: trims Date: 2010-04-01 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/096b18156d91 6940419: Bump the HS18 build number to 02 Summary: Update the HS18 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b3d12e645e7 Author: coleenp Date: 2010-03-12 10:42 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3b3d12e645e7 6929067: Stack guard pages should be removed when thread is detached Summary: Add code to unmap stack guard area when thread is detached. Reviewed-by: coleenp, kamg ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp + test/runtime/6929067/T.java + test/runtime/6929067/Test6929067.sh + test/runtime/6929067/invoke.c Changeset: 0f6600cee529 Author: xlu Date: 2010-03-13 16:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0f6600cee529 6934758: Expose the break down of clean up task time during safepoint. Summary: Use -XX:+TraceSafepointCleanupTime to print out the details of each clean up tasks. Reviewed-by: dholmes, ysr ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp Changeset: 21141e23627a Author: dcubed Date: 2010-03-16 17:47 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/21141e23627a 6923488: 4/4 need minor tweaks to HotSpot build for Cygwin Summary: Clean up get_msc_ver, build.bat and build.make in general and for Cygwin. Reviewed-by: ohair ! make/windows/build.bat ! make/windows/build.make ! make/windows/get_msc_ver.sh Changeset: cd20a6f46fec Author: dcubed Date: 2010-03-16 20:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cd20a6f46fec Merge Changeset: e392695de029 Author: fparain Date: 2010-03-17 11:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e392695de029 6935224: Adding new DTrace probes to work with Palantir Summary: Adding probes related to thread scheduling and class initialization Reviewed-by: kamg, never ! src/os/solaris/dtrace/hotspot.d ! src/os/solaris/vm/attachListener_solaris.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/dtraceAttacher.hpp Changeset: 98ba8ca25feb Author: coleenp Date: 2010-03-18 16:47 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/98ba8ca25feb 6936168: Recent fix for unmapping stack guard pages doesn't close /proc/self/maps Summary: Add close to returns (fix for 6929067 also contributed by aph) Reviewed-by: aph, dcubed, andrew, acorn Contributed-by: aph at redhat.com, andreas.kohn at fredhopper.com ! src/os/linux/vm/os_linux.cpp Changeset: 4f7af0dc447b Author: dcubed Date: 2010-03-23 14:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4f7af0dc447b 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove assert to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/vm/services/management.cpp Changeset: 5d393243d487 Author: dcubed Date: 2010-03-23 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5d393243d487 Merge Changeset: 39e409a664b3 Author: dcubed Date: 2010-03-25 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/39e409a664b3 6938185: 3/4 6923488 breaks Windows command shell builds Summary: Fix build.bat so invoking command shell doesn't exit on error. Fix dirname assumptions. Document some MKS environment dependencies. Reviewed-by: coleenp ! make/windows/build.bat ! make/windows/build.make ! make/windows/create.bat ! make/windows/get_msc_ver.sh Changeset: 84043c7507b9 Author: dcubed Date: 2010-03-25 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/84043c7507b9 Merge Changeset: 4a9cc99938e3 Author: acorn Date: 2010-03-26 11:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4a9cc99938e3 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp Changeset: 7c358fbb6a84 Author: acorn Date: 2010-04-01 11:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7c358fbb6a84 Merge Changeset: 4b60f23c4223 Author: acorn Date: 2010-04-01 20:48 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4b60f23c4223 Merge From tony.printezis at oracle.com Fri Apr 2 12:27:53 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 02 Apr 2010 15:27:53 -0400 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <4BB63B46.7080900@oracle.com> References: <1270211955.23285.8.camel@macbook> <4BB63B46.7080900@oracle.com> Message-ID: <4BB64539.4090508@oracle.com> Y. Srinivas Ramakrishna wrote: > Ah, good point. Yes this should be possible without too much trouble [1] > (both the automatic promotion and/or the pruning) because the scavangable > nmethods list seems to be processed as a separate root-set, so we can > for example send it a special "always promote" Alternatively, we can also set the age of those objects to max_age before passing them to the standard closures. But maybe your suggestion to use a special "always promote" closure is a bit better. Tony > scanner and/or tell the scanner > to drop nmethods that (no longer) have any young refs, the > latter kinda like we do for card scanning. > > Christian or Tom, could one of you please open a CR to track this work > so it isn't > forgotten? > > thanks. > -- ramki > > [1] famous last words? > > > On 04/02/10 11:12, Tom Rodriguez wrote: >> That looks good. We still need logic to prune the list of >> scavengeable nmethods since over time the oops should move out of >> eden and we can then stop scanning those nmethods. Additionally we >> may want GC to automatically promote oops referenced by nmethods >> since they are pretty much guaranteed to be long lived. I don't know >> if there's any easy way to do that. >> >> tom >> >> On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ >>> >>> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations >>> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. >>> Reviewed-by: >>> >>> During testing of JSR 292's SPARC C2 port I found a couple of crashes >>> which came from unfixed code-embedded oops. >>> >>> This can be triggered with ScavengeRootsInCode={1,2}. >>> >>> The fix is to call fix_oop_relocations in >>> CodeCache::scavenge_root_nmethods_do after oops may have been updated. >>> >>> src/share/vm/code/codeCache.cpp >>> >>> >> > From antonios.printezis at sun.com Fri Apr 2 19:36:46 2010 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Sat, 03 Apr 2010 02:36:46 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 2 new changesets Message-ID: <20100403023657.37DFB44EFE@hg.openjdk.java.net> Changeset: 56507bcd639e Author: tonyp Date: 2010-03-30 15:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/56507bcd639e 6937160: G1: should observe GCTimeRatio Summary: Remove the G1GCPercent parameter, that specifies the desired GC overhead percentage in G1, and observe the GCTimeRatio parameter instead. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 781e29eb8e08 Author: tonyp Date: 2010-04-02 12:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/781e29eb8e08 6677708: G1: re-enable parallel RSet updating and scanning Summary: Enable parallel RSet updating and scanning. Reviewed-by: iveresov, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp From tom.rodriguez at oracle.com Mon Apr 5 15:13:47 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 5 Apr 2010 15:13:47 -0700 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <4BB63B46.7080900@oracle.com> References: <1270211955.23285.8.camel@macbook> <4BB63B46.7080900@oracle.com> Message-ID: <08B111BC-FE8C-4596-84C3-221875B9D81D@oracle.com> I filed 6940976 for this. tom On Apr 2, 2010, at 11:45 AM, Y. Srinivas Ramakrishna wrote: > Ah, good point. Yes this should be possible without too much trouble [1] > (both the automatic promotion and/or the pruning) because the scavangable > nmethods list seems to be processed as a separate root-set, so we can > for example send it a special "always promote" scanner and/or tell the scanner > to drop nmethods that (no longer) have any young refs, the > latter kinda like we do for card scanning. > > Christian or Tom, could one of you please open a CR to track this work so it isn't > forgotten? > > thanks. > -- ramki > > [1] famous last words? > > > On 04/02/10 11:12, Tom Rodriguez wrote: >> That looks good. We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods. Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived. I don't know if there's any easy way to do that. >> tom >> On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/ >>> >>> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations >>> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. >>> Reviewed-by: >>> >>> During testing of JSR 292's SPARC C2 port I found a couple of crashes >>> which came from unfixed code-embedded oops. >>> >>> This can be triggered with ScavengeRootsInCode={1,2}. >>> >>> The fix is to call fix_oop_relocations in >>> CodeCache::scavenge_root_nmethods_do after oops may have been updated. >>> >>> src/share/vm/code/codeCache.cpp >>> >>> > From dawn2004 at gmail.com Mon Apr 5 21:57:42 2010 From: dawn2004 at gmail.com (Colin(Du Li)) Date: Mon, 5 Apr 2010 21:57:42 -0700 (PDT) Subject: How to monitor heap access from native threads Message-ID: <28111248.post@talk.nabble.com> Dear all, I wanna monitor all the heap access from native threads. Native threads can access JVM heap in two ways: 1. through JNI function. this will be easier to monitor, and we can instrument the jni function to record the access. 2. Native threads can also get a raw pointer to an objects, then they can access the heap through the raw pointer. For this case, I don't know how to capture and record them. Can anyone give some idea to monitor the memory access from native threads? Any third-party tools I can leverage? Thanks. Colin -- View this message in context: http://old.nabble.com/How-to-monitor-heap-access-from-native-threads-tp28111248p28111248.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Christian.Thalinger at Sun.COM Tue Apr 6 02:18:04 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 06 Apr 2010 11:18:04 +0200 Subject: Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations In-Reply-To: <08B111BC-FE8C-4596-84C3-221875B9D81D@oracle.com> References: <1270211955.23285.8.camel@macbook> <4BB63B46.7080900@oracle.com> <08B111BC-FE8C-4596-84C3-221875B9D81D@oracle.com> Message-ID: <1270545484.2639.7.camel@macbook> On Mon, 2010-04-05 at 15:13 -0700, Tom Rodriguez wrote: > I filed 6940976 for this. Thanks. -- Christian From antonios.printezis at sun.com Tue Apr 6 17:24:36 2010 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Wed, 07 Apr 2010 00:24:36 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 2 new changesets Message-ID: <20100407002455.6F55544423@hg.openjdk.java.net> Changeset: 72f725c5a7be Author: tonyp Date: 2010-04-05 12:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/72f725c5a7be 6940310: G1: MT-unsafe calls to CM::region_stack_push() / CM::region_stack_pop() Summary: Calling the methods region_stack_push() and region_stack_pop() concurrent is not MT-safe. The assumption is that we will only call region_stack_push() during a GC pause and region_stack_pop() during marking. Unfortunately, we also call region_stack_push() during marking which seems to be introducing subtle marking failures. This change introduces lock-based methods for pushing / popping to be called during marking. Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 23b1b27ac76c Author: tonyp Date: 2010-04-06 10:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/23b1b27ac76c 6909756: G1: guarantee(G1CollectedHeap::heap()->mark_in_progress(),"Precondition.") Summary: Make sure that two marking cycles do not overlap, i.e., a new one can only start after the concurrent marking thread finishes all its work. In the fix I piggy-back a couple of minor extra fixes: some general code reformatting for consistency (only around the code I modified), the removal of a field (G1CollectorPolicy::_should_initiate_conc_mark) which doesn't seem to be used at all (it's only set but never read), as well as moving the "is GC locker active" test earlier into the G1 pause / Full GC and using a more appropriate method for it. Reviewed-by: johnc, jmasa, jcoomes, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp From john.cuthbertson at sun.com Wed Apr 7 15:58:32 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Wed, 07 Apr 2010 22:58:32 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6940894: G1: assert(new_obj != 0 || ... "should be forwarded") for compaction tests Message-ID: <20100407225850.3FBE144446@hg.openjdk.java.net> Changeset: bda703475ded Author: johnc Date: 2010-04-07 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bda703475ded 6940894: G1: assert(new_obj != 0 || ... "should be forwarded") for compaction tests Summary: Humongous regions may contain multiple objects as a result of being retained as to-space from a previous GC and then re-used as to-space after being tagged as humongous. These changes include a check that causes retained to-space regions that are now tagged as humongous to be disregarded and a new to-space region allocated. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From antonios.printezis at sun.com Fri Apr 9 14:52:46 2010 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Fri, 09 Apr 2010 21:52:46 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 16 new changesets Message-ID: <20100409215346.A1FC2444C1@hg.openjdk.java.net> Changeset: fdd57634910e Author: never Date: 2010-03-18 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fdd57634910e 6926979: should simplify catch_inline_exception Reviewed-by: twisti ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/globals.hpp Changeset: 747d26efc5fa Author: twisti Date: 2010-03-30 00:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/747d26efc5fa 6939180: Zero locking fix Summary: When Zero is running with Shark enabled threads can be left with their _do_not_unlock_if_synchronized flag incorrectly set. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: 47742b654fcb Author: twisti Date: 2010-03-31 08:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/47742b654fcb 6939731: JSR 292 Zero build fix after 6934494 Summary: The changes of 6934494 have broken the Zero build. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.hpp Changeset: f61d795ce6de Author: never Date: 2010-03-31 11:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f61d795ce6de 6939845: zero needs fallback path in C++ interpreter for platform dependent fast bytecodes Reviewed-by: never Contributed-by: ed at camswl.com ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 7f4deda46b04 Author: never Date: 2010-03-31 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7f4deda46b04 Merge Changeset: 547cbe6dacc5 Author: never Date: 2010-04-01 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/547cbe6dacc5 6936709: AsyncGetCallTrace doesn't handle inexact stack walking properly Reviewed-by: kvn ! src/share/vm/prims/forte.cpp Changeset: 1c9c45172908 Author: kvn Date: 2010-04-02 11:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1c9c45172908 6939804: ciConstant::print() prints incorrect bool value Summary: Fix typo. Reviewed-by: never ! src/share/vm/ci/ciConstant.cpp Changeset: 9bb91718aaf2 Author: kvn Date: 2010-04-02 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9bb91718aaf2 Merge ! src/share/vm/runtime/globals.hpp Changeset: b5d78a3b8843 Author: kvn Date: 2009-12-03 14:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b5d78a3b8843 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Summary: Use size_t type cast to widen int values in typeArrayKlass::copy_array(). Reviewed-by: never, jcoomes ! src/share/vm/oops/typeArrayKlass.cpp + test/compiler/6892265/Test.java Changeset: ae4032fb0a5b Author: kvn Date: 2010-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ae4032fb0a5b 6894807: No ClassCastException for HashAttributeSet constructors if run with -Xcomp Summary: Return interface klass type if it is exact. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp Changeset: 0c3f888b7636 Author: acorn Date: 2010-01-19 16:03 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0c3f888b7636 6626217: Fixed loader constraint array handling Summary: Loader constraints track array elements, not arrays themselves. Reviewed-by: dcubed, kevinw ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3d531bbe5917 Author: acorn Date: 2010-01-28 13:59 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3d531bbe5917 Merge Changeset: f5dd08ad65df Author: acorn Date: 2010-03-15 15:51 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f5dd08ad65df 6932480: Fix crash in CompilerThread/Parser. Unloaded array klass? Summary: Restore code deleted in 6626217 Reviewed-by: asaha, kevinw ! src/share/vm/ci/ciEnv.cpp Changeset: 09ac706c2623 Author: asaha Date: 2010-03-24 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/09ac706c2623 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp - src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp ! src/share/vm/opto/type.cpp Changeset: 895d9ade6111 Author: asaha Date: 2010-04-06 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/895d9ade6111 Merge ! src/share/vm/opto/type.cpp Changeset: 6b73e879f1c2 Author: tonyp Date: 2010-04-09 13:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6b73e879f1c2 Merge From shane.cox at gmail.com Tue Apr 13 09:58:02 2010 From: shane.cox at gmail.com (Shane Cox) Date: Tue, 13 Apr 2010 12:58:02 -0400 Subject: UseNUMA flag Message-ID: Is -XX:+UseNUMA specific to the parallel throughput collector (-XX:+UseParallelGC) or would it also help when running the CMS collector (-XX:+ParNewGC)? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100413/29aab914/attachment.html From tony.printezis at oracle.com Tue Apr 13 10:00:43 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 13 Apr 2010 13:00:43 -0400 Subject: UseNUMA flag In-Reply-To: References: Message-ID: <4BC4A33B.5010500@oracle.com> Shane, +UseNUMA only works for the parallel GC. Tony On 4/13/2010 12:58 PM, Shane Cox wrote: > Is -XX:+UseNUMA specific to the parallel throughput collector > (-XX:+UseParallelGC) or would it also help when running the CMS > collector (-XX:+ParNewGC)? > > Thanks From matt.khan at db.com Tue Apr 13 10:46:09 2010 From: matt.khan at db.com (Matt Khan) Date: Tue, 13 Apr 2010 18:46:09 +0100 Subject: Does allocation performance vary by collector? Message-ID: Hi I have been revisiting our jvm configuration with the aim of reducing pause times, it would be nice to be consistently down below 3ms all the time. The allocation behaviour of the application in question involves a small amount of static data on startup & then a steady stream of objects that have a relatively short lifespan. There are 2 typical lifetimes of these objects with about 75% while the remainder have a mean of maybe 70s but there is a quite a long tail to this so the typical lifetime is more like <10s. There won't be many such objects alive at once but there are quite a few passing through. The app runs on a 16 core opteron box running Solaris 10 with 6u18. Therefore I've been benching different configurations with a massive eden and relatively tiny tenured & trying different collectors to see how they perform. These params were common to each run -Xms3072m -Xmx3072m -Xmn2944m -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=190 -XX:TargetSurvivorRatio=90 I then tried the following # Parallel Scavenge -XX:+UseParallelGC -XX:+UseParallelOldGC # Parallel Scavenge with NUMA -XX:+UseParallelGC -XX:+UseNUMA -XX:+UseParallelOldGC # Incremental CMS/ParNew -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+UseParNewGC # G1 -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC The last two (CMS/G1) were repeated on 6u18 & 6u20b02 for completeness as I see there were assorted fixes to G1 in 6u20b01. I measure the time it takes to execute assorted points in my flow & see fairly significant differences in latencies with each collector, for example 1) CMS == ~380-400micros 2) Parallel + NUMA == ~400micros 3) Parallel == ~450micros 4) G1 == ~550micros The times above are taken well after the jvm has warmed up (latencies have stabilised, compilation activity is practically non-existent) & there is no significant "other" activity on the server at the time. The differences don't appear to be pause related as the shape of the distribution (around those averages) is the same, it's as if it has settled into quite a different steady state performance. This appears to be repeatable though, given the time it takes to run this sort of benchmark, I admit to only have seen it repeated a few times. I have run previous benchmarks where it repeats it 20x times (keeping GC constant in this case, was testing something else) without seeing variations that big across runs which makes me suspect the collection algorithm as the culprit. So the point of this relatively long setup is to ask whether there are theoretical reasons why the choice of garbage collection algorithm should vary measured latency like this? I had been working on the assumption that eden allocation is a "bump the pointer as you take it from a TLAB" type of event hence generally cheap & doesn't really vary by algorithm. fwiw the ParNew/CMS config is still the best one for keeping down pause times though the parallel one was close. The former peaks at intermittent pauses of 20-30ms, the latter at about 40ms. The Parallel + NUMA one curiously involved many fewer pauses such that much less time was spent paused but peaked higher (~120ms) which are unacceptable really. I don't really understand why that is but speculated that it's down to the fact that one of our key domain objects is allocated in a different thread to where it is primarily used. Is this right? If there is some other data that I should post to back up some of the above then pls tell me and I'll add the info if I have it (and repeat the test if I don't) Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. From matt.khan at db.com Tue Apr 13 10:52:09 2010 From: matt.khan at db.com (Matt Khan) Date: Tue, 13 Apr 2010 18:52:09 +0100 Subject: Does allocation performance vary by collector? In-Reply-To: Message-ID: >> There are 2 typical lifetimes of these objects with about 75% this should have read as "with about 75% surviving for <1s" Cheers Matt hotspot-gc-dev-bounces at openjdk.java.net wrote on 13/04/2010 18:46:09: > Hi > > I have been revisiting our jvm configuration with the aim of reducing > pause times, it would be nice to be consistently down below 3ms all the > time. The allocation behaviour of the application in question involves a > small amount of static data on startup & then a steady stream of objects > that have a relatively short lifespan. There are 2 typical lifetimes of > these objects with about 75% while the remainder have a mean of maybe 70s > but there is a quite a long tail to this so the typical lifetime is more > like <10s. There won't be many such objects alive at once but there are > quite a few passing through. The app runs on a 16 core opteron box running > Solaris 10 with 6u18. > --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. From yamauchi at google.com Tue Apr 13 11:21:11 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Tue, 13 Apr 2010 11:21:11 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: <4BB4C3A4.40701@oracle.com> References: <4B9E8499.8030904@sun.com> <4BA0087A.2040006@Sun.COM> <4BA3AE88.3090002@sun.com> <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> Message-ID: Hi Jon, I finally got to this. Here's the webrev for a second version based on our discussion (thanks to Chuck Rasbold): http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ The summary of change is that the logic for expansion based on MinHeapFreeRatio was added and only the flag for the System.gc was retained (and renamed to PSResizeByFreeRatioWithSystemGC.) Thanks, Hiroshi On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu wrote: > On 03/31/10 11:26, Hiroshi Yamauchi wrote: >> >> >> ... >> >> I think we agree that it's a good idea to try to shrink the heap in >> response to System.gc() in such a scenario/app. > > Yes on the shrinking on a System.gc() and perhaps for symmetry also > expanding > a small heap to MinFreeHeapRatio? ?UseAdaptiveSizePolicy will shrink the > heap > down during periods of low activity and it might be useful to swiftly expand > the > heap on a System.gc(). >> >> Since we are talking about a setting where the free ratio flags takes >> precedence over the psAdaptiveSizePolicy's throughput goals, the suggested >> logic in the original webrev is perhaps not so terrible? If so, I suppose >> the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with that >> because it can shrink the heap regardless of the throughput goal. It may >> make sense to remove UseFreeRatioForParallelGC and keep >> UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it happen >> inside psAdaptiveSizePolicy instead, the current webrev does not work. >> > I like the structure of the original webrev with regard to the logic for > using FreeRation. ?It's simpler than embedding it in the > PSAdaptivesizePolicy. > > > 243 ? ? if (UseFreeRatioOnlyInSystemGCForParallelGC && > 245 ? ? ? ? ? gc_cause == GCCause::_java_lang_system_gc)) { > ? ? ? ? ?compute_new_size(); ?<<<<<<<< ?generalization of > ? ? ? ? ? ? ?<<<<<<<< ?try_to_shrink_by_free_ratio() > 248 ? ? } else { > ? ? ? ? ?use current UseAdaptiveSizePolicy > ? ? ? ?} > > > > > From y.s.ramakrishna at oracle.com Tue Apr 13 11:32:41 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 13 Apr 2010 11:32:41 -0700 Subject: UseNUMA flag In-Reply-To: References: Message-ID: <4BC4B8C9.5010102@oracle.com> On 04/13/10 09:58, Shane Cox wrote: > Is -XX:+UseNUMA specific to the parallel throughput collector > (-XX:+UseParallelGC) or would it also help when running the CMS > collector (-XX:+ParNewGC)? It hasn't yet been extended to work with anything other than UseParallelGC's eden allocation; but there are plans on the cards to extend it to work with other collectors in the future as well as making the collectors numa-aware. So, no, +UseNUMA will not provide any current benefit with CMS/ParNew. -- ramki From jon.masamitsu at oracle.com Tue Apr 13 19:08:54 2010 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 14 Apr 2010 02:08:54 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6858496: Clear all SoftReferences before an out-of-memory due to GC overhead limit. Message-ID: <20100414020909.6D72D4453B@hg.openjdk.java.net> Changeset: 0bfd3fb24150 Author: jmasa Date: 2010-04-13 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0bfd3fb24150 6858496: Clear all SoftReferences before an out-of-memory due to GC overhead limit. Summary: Ensure a full GC that clears SoftReferences before throwing an out-of-memory Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp From matt.khan at db.com Wed Apr 14 04:28:03 2010 From: matt.khan at db.com (Matt Khan) Date: Wed, 14 Apr 2010 12:28:03 +0100 Subject: Avoiding 1 long CMS with a big heap Message-ID: Hi I have been experimenting with larger heap sizes to see if I can reduce the frequency of my pauses, the switches I have used are; -Xms16192m -Xmx16192m -Xmn16000m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+UseParNewGC -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution -XX:SurvivorRatio=1022 -XX:TargetSurvivorRatio=90 -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime This works quite well in that our average pause time is ~4ms every 30s or so (albeit in the range 5-60s but most commonly about every 30s). There is one wrinkle and that is an initial, v long CMS pause. It happens about ~40mins after start 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 sys=0.06, real=4.22 secs] Total time for which application threads were stopped: 4.2243800 seconds 2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start] Application time: 0.0021391 seconds Total time for which application threads were stopped: 0.0046091 seconds 2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 secs] [Times: user=0.35 sys=0.15, real=0.06 secs] 2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start] 2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 2010-04-13T23:05:33.347+0000: 3347.129: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: [CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 sys=0.24, real=5.11 secs] Application time: 4.1574245 seconds 2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K (16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] 7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, real=4.23 secs] Total time for which application threads were stopped: 4.2351364 seconds 2010-04-13T23:05:42.692+0000: 3356.473: [CMS-concurrent-sweep-start] Application time: 0.0003415 seconds What I would like to understand is why there is such a long pause when the tenured is nowhere near full (~12m of 192m occupied)? and hence whether this can be avoided? Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Matt.Bollier at cmegroup.com Wed Apr 14 06:28:20 2010 From: Matt.Bollier at cmegroup.com (Bollier, Matt) Date: Wed, 14 Apr 2010 08:28:20 -0500 Subject: Does allocation performance vary by collector? In-Reply-To: References: Message-ID: <7765CD3CAF8DD94792439095242327810A93608432@SMAPEXMBX1.prod.ad.merc.chicago.cme.com> My understanding is that -Xmn is not respected when using the G1 collector. Try using -XX:G1YoungGenSize=2944m instead. -----Original Message----- From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Matt Khan Sent: Tuesday, April 13, 2010 12:46 PM To: hotspot-gc-dev at openjdk.java.net Subject: Does allocation performance vary by collector? Hi I have been revisiting our jvm configuration with the aim of reducing pause times, it would be nice to be consistently down below 3ms all the time. The allocation behaviour of the application in question involves a small amount of static data on startup & then a steady stream of objects that have a relatively short lifespan. There are 2 typical lifetimes of these objects with about 75% while the remainder have a mean of maybe 70s but there is a quite a long tail to this so the typical lifetime is more like <10s. There won't be many such objects alive at once but there are quite a few passing through. The app runs on a 16 core opteron box running Solaris 10 with 6u18. Therefore I've been benching different configurations with a massive eden and relatively tiny tenured & trying different collectors to see how they perform. These params were common to each run -Xms3072m -Xmx3072m -Xmn2944m -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=190 -XX:TargetSurvivorRatio=90 I then tried the following # Parallel Scavenge -XX:+UseParallelGC -XX:+UseParallelOldGC # Parallel Scavenge with NUMA -XX:+UseParallelGC -XX:+UseNUMA -XX:+UseParallelOldGC # Incremental CMS/ParNew -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+UseParNewGC # G1 -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC The last two (CMS/G1) were repeated on 6u18 & 6u20b02 for completeness as I see there were assorted fixes to G1 in 6u20b01. I measure the time it takes to execute assorted points in my flow & see fairly significant differences in latencies with each collector, for example 1) CMS == ~380-400micros 2) Parallel + NUMA == ~400micros 3) Parallel == ~450micros 4) G1 == ~550micros The times above are taken well after the jvm has warmed up (latencies have stabilised, compilation activity is practically non-existent) & there is no significant "other" activity on the server at the time. The differences don't appear to be pause related as the shape of the distribution (around those averages) is the same, it's as if it has settled into quite a different steady state performance. This appears to be repeatable though, given the time it takes to run this sort of benchmark, I admit to only have seen it repeated a few times. I have run previous benchmarks where it repeats it 20x times (keeping GC constant in this case, was testing something else) without seeing variations that big across runs which makes me suspect the collection algorithm as the culprit. So the point of this relatively long setup is to ask whether there are theoretical reasons why the choice of garbage collection algorithm should vary measured latency like this? I had been working on the assumption that eden allocation is a "bump the pointer as you take it from a TLAB" type of event hence generally cheap & doesn't really vary by algorithm. fwiw the ParNew/CMS config is still the best one for keeping down pause times though the parallel one was close. The former peaks at intermittent pauses of 20-30ms, the latter at about 40ms. The Parallel + NUMA one curiously involved many fewer pauses such that much less time was spent paused but peaked higher (~120ms) which are unacceptable really. I don't really understand why that is but speculated that it's down to the fact that one of our key domain objects is allocated in a different thread to where it is primarily used. Is this right? If there is some other data that I should post to back up some of the above then pls tell me and I'll add the info if I have it (and repeat the test if I don't) Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. From jon.masamitsu at oracle.com Wed Apr 14 06:57:34 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 14 Apr 2010 06:57:34 -0700 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: References: Message-ID: <4BC5C9CE.4060309@oracle.com> Matt, What jdk release are you using? Can you send the GC log for a few of the young generation collections before the initial mark (the very long pause of ~ 4secs)? For a few young generation collections after the end of the CMS cycle may be interesting too. Does the long pause occur with every initial mark (CMS-initial-mark) or just the first one? What type of platform are you running on? Why are you using CMSIncrementalMode? You seem to have decided to promote (copy to the tenured generation) everything that survives a young gen collection (small MaxTenuringThreshold, small survivor spaces). Is that to minimize the young gen collection pauses? Jon On 04/14/10 04:28, Matt Khan wrote: > Hi > > I have been experimenting with larger heap sizes to see if I can reduce > the frequency of my pauses, the switches I have used are; > > -Xms16192m > -Xmx16192m > -Xmn16000m > -XX:+UseCompressedOops > -XX:+UseConcMarkSweepGC > -XX:+CMSIncrementalMode > -XX:+CMSIncrementalPacing > -XX:+UseParNewGC > -XX:MaxTenuringThreshold=1 > -XX:+PrintTenuringDistribution > -XX:SurvivorRatio=1022 > -XX:TargetSurvivorRatio=90 > -XX:+DisableExplicitGC > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime > > This works quite well in that our average pause time is ~4ms every 30s or > so (albeit in the range 5-60s but most commonly about every 30s). > > There is one wrinkle and that is an initial, v long CMS pause. It happens > about ~40mins after start > > 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: > 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 > sys=0.06, real=4.22 secs] > Total time for which application threads were stopped: 4.2243800 seconds > 2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start] > Application time: 0.0021391 seconds > Total time for which application threads were stopped: 0.0046091 seconds > 2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 > secs] [Times: user=0.35 sys=0.15, real=0.06 secs] > 2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start] > 2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: > 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] > 2010-04-13T23:05:33.347+0000: 3347.129: > [CMS-concurrent-abortable-preclean-start] > CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: > [CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 > sys=0.24, real=5.11 secs] > Application time: 4.1574245 seconds > 2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K > (16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak > refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] > 7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, > real=4.23 secs] > Total time for which application threads were stopped: 4.2351364 seconds > 2010-04-13T23:05:42.692+0000: 3356.473: [CMS-concurrent-sweep-start] > Application time: 0.0003415 seconds > > What I would like to understand is why there is such a long pause when the > tenured is nowhere near full (~12m of 192m occupied)? and hence whether > this can be avoided? > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/8a77c03a/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From matt.khan at db.com Wed Apr 14 07:24:05 2010 From: matt.khan at db.com (Matt Khan) Date: Wed, 14 Apr 2010 15:24:05 +0100 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: <4BC5C9CE.4060309@oracle.com> Message-ID: Hi Jon >> What jdk release are you using? 6u18 >> What type of platform are you running on? Solaris 10 x86 (Sun x4600) >> You seem to have decided to promote (copy to the tenured generation) everything that survives a young gen collection (small MaxTenuringThreshold, small survivor spaces). Is that to minimize the young gen collection pauses? this post ( http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2010-April/001671.html) has a bit more info on our allocation behaviour. Basically there is static data loaded at startup and then mostly things don't last v long before they're eligible for eviction. Therefore my thinking is that since the set of live objects at any one time is small and they don't last long then the probability of anything surviving 2 young collections is minimal and therefore I might as well increase the interval between young collections marginally by making active use of that space in eden. The target is simply consistently low pauses. >> Why are you using CMSIncrementalMode? in the past we found that it helps smooth out the pause times a little, I left it in on this run to minimise the no of changes between what we have now and what I'm benching. I was expecting a single CMS run and no more tbh as I was working on the understanding that it always has one CMS event near startup in order to collect some stats on what is going on. >> Does the long pause occur with every initial mark (CMS-initial-mark) or just the first one? benchmark has run for 16hrs so far and there have been 2 initial marks so far, the first one I expected but the 2nd one I didn't. 2010-04-13T22:09:58.463+0000: 12.249: [GC [1 CMS-initial-mark: 3679K(196608K)] 3679K(16564608K), 0.0009694 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 sys=0.06, real=4.22 secs] >> Can you send the GC log for a few of the young generation collections before the initial mark (the very long pause of ~ 4secs)? here you go, have stripped out the stopped/concurrent time entries to show all the GC events leading upto the long pause & the next 5 young collections. 2010-04-13T22:09:58.234+0000: 12.019: [Full GC 12.021: [CMS: 0K->3679K(196608K), 0.2269262 secs] 4251520K->3679K(16564608K), [CMS Perm : 21247K->21209K(21248K)], 0.2286580 secs] [Times: user=0.22 sys=0.01, real=0.23 secs] 2010-04-13T22:09:58.463+0000: 12.249: [GC [1 CMS-initial-mark: 3679K(196608K)] 3679K(16564608K), 0.0009694 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 2010-04-13T22:09:58.464+0000: 12.250: [CMS-concurrent-mark-start] 2010-04-13T22:10:01.522+0000: 15.308: [CMS-concurrent-mark: 0.024/3.058 secs] [Times: user=3.29 sys=1.09, real=3.06 secs] 2010-04-13T22:10:01.522+0000: 15.308: [CMS-concurrent-preclean-start] 2010-04-13T22:10:01.539+0000: 15.325: [CMS-concurrent-preclean: 0.016/0.017 secs] [Times: user=0.03 sys=0.05, real=0.02 secs] 2010-04-13T22:10:01.539+0000: 15.325: [CMS-concurrent-abortable-preclean-start] 2010-04-13T22:10:08.650+0000: 22.436: [GC 22.437: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 8049864 bytes, 8049864 total - age 2: 112 bytes, 8049976 total : 16352000K->7981K(16368000K), 0.0305746 secs] 16355679K->11661K(16564608K), 0.0312194 secs] [Times: user=0.14 sys=0.05, real=0.03 secs] CMS: abort preclean due to time 2010-04-13T22:13:56.812+0000: 250.598: [CMS-concurrent-abortable-preclean: 0.013/235.273 secs] [Times: user=48.48 sys=11.66, real=235.27 secs] 2010-04-13T22:13:56.814+0000: 250.599: [GC[YG occupancy: 7376304 K (16368000 K)]250.600: [Rescan (parallel) , 1.9740400 secs]252.574: [weak refs processing, 0.0015189 secs] [1 CMS-remark: 3679K(196608K)] 7379983K(16564608K), 1.9759675 secs] [Times: user=17.08 sys=0.82, real=1.98 secs] 2010-04-13T22:13:58.791+0000: 252.576: [CMS-concurrent-sweep-start] 2010-04-13T22:13:58.796+0000: 252.581: [CMS-concurrent-sweep: 0.005/0.005 secs] [Times: user=0.04 sys=0.02, real=0.01 secs] 2010-04-13T22:13:58.800+0000: 252.585: [CMS-concurrent-reset-start] 2010-04-13T22:13:58.805+0000: 252.591: [CMS-concurrent-reset: 0.006/0.006 secs] [Times: user=0.03 sys=0.01, real=0.01 secs] 2010-04-13T22:47:09.067+0000: 2242.850: [GC 2242.851: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 7803368 bytes, 7803368 total : 16359981K->12388K(16368000K), 0.0589077 secs] 16363570K->24406K(16564608K) icms_dc=5 , 0.0593692 secs] [Times: user=0.18 sys=0.06, real=0.06 secs] 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 sys=0.06, real=4.22 secs] 2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start] 2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 secs] [Times: user=0.35 sys=0.15, real=0.06 secs] 2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start] 2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 2010-04-13T23:05:33.347+0000: 3347.129: [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: [CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 sys=0.24, real=5.11 secs] 2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K (16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] 7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, real=4.23 secs] 2010-04-13T23:05:42.692+0000: 3356.473: [CMS-concurrent-sweep-start] 2010-04-13T23:05:42.765+0000: 3356.547: [CMS-concurrent-sweep: 0.018/0.074 secs] [Times: user=0.13 sys=0.05, real=0.07 secs] 2010-04-13T23:05:42.768+0000: 3356.549: [CMS-concurrent-reset-start] 2010-04-13T23:05:42.771+0000: 3356.552: [CMS-concurrent-reset: 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 2010-04-13T23:40:49.463+0000: 5463.242: [GC 5463.243: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 4876232 bytes, 4876232 total : 16364388K->6895K(16368000K), 0.0338554 secs] 16375925K->21493K(16564608K) icms_dc=0 , 0.0342923 secs] [Times: user=0.12 sys=0.04, real=0.03 secs] 2010-04-14T00:41:32.410+0000: 9106.186: [GC 9106.186: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 7471944 bytes, 7471944 total : 16358895K->8975K(16368000K), 0.0301672 secs] 16373493K->23921K(16564608K) icms_dc=0 , 0.0306159 secs] [Times: user=0.12 sys=0.03, real=0.03 secs] 2010-04-14T01:42:59.422+0000: 12793.193: [GC 12793.193: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 6720592 bytes, 6720592 total : 16360975K->10859K(16368000K), 0.1057987 secs] 16375921K->28778K(16564608K) icms_dc=0 , 0.1062338 secs] [Times: user=0.12 sys=0.14, real=0.11 secs] 2010-04-14T02:46:12.795+0000: 16586.561: [GC 16586.561: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 6370400 bytes, 6370400 total : 16362859K->7334K(16368000K), 0.0498029 secs] 16380778K->27405K(16564608K) icms_dc=0 , 0.0502474 secs] [Times: user=0.10 sys=0.04, real=0.05 secs] 2010-04-14T03:54:06.986+0000: 20660.747: [GC 20660.747: [ParNew Desired survivor size 14745600 bytes, new threshold 1 (max 1) - age 1: 5864544 bytes, 5864544 total : 16359334K->8803K(16368000K), 0.0434378 secs] 16379405K->30657K(16564608K) icms_dc=0 , 0.0439089 secs] [Times: user=0.10 sys=0.03, real=0.04 secs] Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From matt.khan at db.com Wed Apr 14 07:31:05 2010 From: matt.khan at db.com (Matt Khan) Date: Wed, 14 Apr 2010 15:31:05 +0100 Subject: Does allocation performance vary by collector? In-Reply-To: <7765CD3CAF8DD94792439095242327810A93608432@SMAPEXMBX1.prod.ad.merc.chicago.cme.com> Message-ID: >> My understanding is that -Xmn is not respected when using the G1 collector. Try using -XX:G1YoungGenSize=2944m instead. I thought it was honoured as a result of this http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6928059 IIRC my (6u20b02) JVM failed to start when I used G1YoungGenSize Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. From tony.printezis at oracle.com Wed Apr 14 07:54:07 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Apr 2010 10:54:07 -0400 Subject: Does allocation performance vary by collector? In-Reply-To: <7765CD3CAF8DD94792439095242327810A93608432@SMAPEXMBX1.prod.ad.merc.chicago.cme.com> References: <7765CD3CAF8DD94792439095242327810A93608432@SMAPEXMBX1.prod.ad.merc.chicago.cme.com> Message-ID: <4BC5D70F.7090305@oracle.com> Matt, We've been normalizing the G1 parameters (so that they conform to the existing ones as much as possible). So, the latest G1 observes -Xmn, NewSize, NewRatio, etc. FWIW. Tony Bollier, Matt wrote: > My understanding is that -Xmn is not respected when using the G1 collector. Try using -XX:G1YoungGenSize=2944m instead. > > -----Original Message----- > From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Matt Khan > Sent: Tuesday, April 13, 2010 12:46 PM > To: hotspot-gc-dev at openjdk.java.net > Subject: Does allocation performance vary by collector? > > Hi > > I have been revisiting our jvm configuration with the aim of reducing > pause times, it would be nice to be consistently down below 3ms all the > time. The allocation behaviour of the application in question involves a > small amount of static data on startup & then a steady stream of objects > that have a relatively short lifespan. There are 2 typical lifetimes of > these objects with about 75% while the remainder have a mean of maybe 70s > but there is a quite a long tail to this so the typical lifetime is more > like <10s. There won't be many such objects alive at once but there are > quite a few passing through. The app runs on a 16 core opteron box running > Solaris 10 with 6u18. > > Therefore I've been benching different configurations with a massive eden > and relatively tiny tenured & trying different collectors to see how they > perform. These params were common to each run > > -Xms3072m > -Xmx3072m > -Xmn2944m > -XX:+DisableExplicitGC > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=190 > -XX:TargetSurvivorRatio=90 > > I then tried the following > > # Parallel Scavenge > -XX:+UseParallelGC > -XX:+UseParallelOldGC > > # Parallel Scavenge with NUMA > -XX:+UseParallelGC > -XX:+UseNUMA > -XX:+UseParallelOldGC > > # Incremental CMS/ParNew > -XX:+UseConcMarkSweepGC > -XX:+CMSIncrementalMode > -XX:+CMSIncrementalPacing > -XX:+UseParNewGC > > # G1 > -XX:+UnlockExperimentalVMOptions > -XX:+UseG1GC > > The last two (CMS/G1) were repeated on 6u18 & 6u20b02 for completeness as > I see there were assorted fixes to G1 in 6u20b01. > > I measure the time it takes to execute assorted points in my flow & see > fairly significant differences in latencies with each collector, for > example > > 1) CMS == ~380-400micros > 2) Parallel + NUMA == ~400micros > 3) Parallel == ~450micros > 4) G1 == ~550micros > > The times above are taken well after the jvm has warmed up (latencies have > stabilised, compilation activity is practically non-existent) & there is > no significant "other" activity on the server at the time. The differences > don't appear to be pause related as the shape of the distribution (around > those averages) is the same, it's as if it has settled into quite a > different steady state performance. This appears to be repeatable though, > given the time it takes to run this sort of benchmark, I admit to only > have seen it repeated a few times. I have run previous benchmarks where it > repeats it 20x times (keeping GC constant in this case, was testing > something else) without seeing variations that big across runs which makes > me suspect the collection algorithm as the culprit. > > So the point of this relatively long setup is to ask whether there are > theoretical reasons why the choice of garbage collection algorithm should > vary measured latency like this? I had been working on the assumption that > eden allocation is a "bump the pointer as you take it from a TLAB" type of > event hence generally cheap & doesn't really vary by algorithm. > > fwiw the ParNew/CMS config is still the best one for keeping down pause > times though the parallel one was close. The former peaks at intermittent > pauses of 20-30ms, the latter at about 40ms. The Parallel + NUMA one > curiously involved many fewer pauses such that much less time was spent > paused but peaked higher (~120ms) which are unacceptable really. I don't > really understand why that is but speculated that it's down to the fact > that one of our key domain objects is allocated in a different thread to > where it is primarily used. Is this right? > > If there is some other data that I should post to back up some of the > above then pls tell me and I'll add the info if I have it (and repeat the > test if I don't) > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. > From y.s.ramakrishna at oracle.com Wed Apr 14 08:42:43 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 14 Apr 2010 08:42:43 -0700 Subject: Does allocation performance vary by collector? In-Reply-To: References: Message-ID: <4BC5E273.3040703@oracle.com> Hi Matt -- if you are really trying to measure pure allocation throughput you might want to completely eliminate GC overhead by making sure yr instrumentation collects figures over an interval during which no GC activity intervenes. I would typically expect NUMA(Parallel) to be better than the rest, but just as you stated in your example certain allocation+use patterns could degrade performance. Other than that (except for G1 see below) all other configurations (modulo GC overhead remarks above) should show similar allocation performance. G1 uses "heap regions" which might somewhat limit TLAB growth and might cause slightly lower allocation throughput (but not necessarily; run the non-G1 collector with +PrintTLABStatistics to get some data on TLAB sizes). However, you can try to fix that by choosing a larger heap region size in G1. (G1 cognoscenti on the list can provide more details.) However, I see that you are interested not just in allocation performance but latency of yr operations in general (which is why you were concerned with GC pause times themselves). In that case, you are right that CMS or G1 would probably be superior if you had a large heap footprint so as to get whole heap GC's (or at least if enough objects got promoted to old gen so as to require the occasional full gc). Between G1 and CMS, G1 generally provides much more regular and predictable GC pauses, but for a truly apples-to-apples comparison you cannot assume that the optimal heap shape for CMS is the same as that for G1. CMS needs hand tuning and G1 finds something close to optimal (but might occasionally need some help) -- thus paradoxically, unless you have been careful setting the heap shape for G1 might be suboptimal, especially if you merely took the CMS optimal setting and used it with G1. If you can arrange to have nothing promoted into the old gen ever then, provided the lifetimes of objects are not too long (so you would spend effort copying between survivor spaces), Parallel+NUMA may be best, modulo the caveats about NUMA-allocator anti-patterns above. One final remark: rather than looking at averages or other central measures, i'd suggest looking at latency distribution metrics to quickly get a handle on what is happening, and how to tune/configure which collector for your needs. -- ramki On 04/13/10 10:46, Matt Khan wrote: > Hi > > I have been revisiting our jvm configuration with the aim of reducing > pause times, it would be nice to be consistently down below 3ms all the > time. The allocation behaviour of the application in question involves a > small amount of static data on startup & then a steady stream of objects > that have a relatively short lifespan. There are 2 typical lifetimes of > these objects with about 75% while the remainder have a mean of maybe 70s > but there is a quite a long tail to this so the typical lifetime is more > like <10s. There won't be many such objects alive at once but there are > quite a few passing through. The app runs on a 16 core opteron box running > Solaris 10 with 6u18. > > Therefore I've been benching different configurations with a massive eden > and relatively tiny tenured & trying different collectors to see how they > perform. These params were common to each run > > -Xms3072m > -Xmx3072m > -Xmn2944m > -XX:+DisableExplicitGC > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=190 > -XX:TargetSurvivorRatio=90 > > I then tried the following > > # Parallel Scavenge > -XX:+UseParallelGC > -XX:+UseParallelOldGC > > # Parallel Scavenge with NUMA > -XX:+UseParallelGC > -XX:+UseNUMA > -XX:+UseParallelOldGC > > # Incremental CMS/ParNew > -XX:+UseConcMarkSweepGC > -XX:+CMSIncrementalMode > -XX:+CMSIncrementalPacing > -XX:+UseParNewGC > > # G1 > -XX:+UnlockExperimentalVMOptions > -XX:+UseG1GC > > The last two (CMS/G1) were repeated on 6u18 & 6u20b02 for completeness as > I see there were assorted fixes to G1 in 6u20b01. > > I measure the time it takes to execute assorted points in my flow & see > fairly significant differences in latencies with each collector, for > example > > 1) CMS == ~380-400micros > 2) Parallel + NUMA == ~400micros > 3) Parallel == ~450micros > 4) G1 == ~550micros > > The times above are taken well after the jvm has warmed up (latencies have > stabilised, compilation activity is practically non-existent) & there is > no significant "other" activity on the server at the time. The differences > don't appear to be pause related as the shape of the distribution (around > those averages) is the same, it's as if it has settled into quite a > different steady state performance. This appears to be repeatable though, > given the time it takes to run this sort of benchmark, I admit to only > have seen it repeated a few times. I have run previous benchmarks where it > repeats it 20x times (keeping GC constant in this case, was testing > something else) without seeing variations that big across runs which makes > me suspect the collection algorithm as the culprit. > > So the point of this relatively long setup is to ask whether there are > theoretical reasons why the choice of garbage collection algorithm should > vary measured latency like this? I had been working on the assumption that > eden allocation is a "bump the pointer as you take it from a TLAB" type of > event hence generally cheap & doesn't really vary by algorithm. > > fwiw the ParNew/CMS config is still the best one for keeping down pause > times though the parallel one was close. The former peaks at intermittent > pauses of 20-30ms, the latter at about 40ms. The Parallel + NUMA one > curiously involved many fewer pauses such that much less time was spent > paused but peaked higher (~120ms) which are unacceptable really. I don't > really understand why that is but speculated that it's down to the fact > that one of our key domain objects is allocated in a different thread to > where it is primarily used. Is this right? > > If there is some other data that I should post to back up some of the > above then pls tell me and I'll add the info if I have it (and repeat the > test if I don't) > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. From tony.printezis at oracle.com Wed Apr 14 09:57:11 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Wed, 14 Apr 2010 16:57:11 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6937142: G1: improvements to debugging output (S-M) Message-ID: <20100414165721.BDD2044550@hg.openjdk.java.net> Changeset: 7666957bc44d Author: tonyp Date: 2010-03-30 15:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7666957bc44d 6937142: G1: improvements to debugging output (S-M) Summary: Various fixes to the G1 debugging output. Reviewed-by: johnc, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp From jon.masamitsu at oracle.com Wed Apr 14 10:37:19 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 14 Apr 2010 10:37:19 -0700 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: References: Message-ID: <4BC5FD4F.6030506@oracle.com> On 04/14/10 07:24, Matt Khan wrote: > > > 2010-04-13T22:47:09.067+0000: 2242.850: [GC 2242.851: [ParNew > Desired survivor size 14745600 bytes, new threshold 1 (max 1) > - age 1: 7803368 bytes, 7803368 total > : 16359981K->12388K(16368000K), 0.0589077 secs] > 16363570K->24406K(16564608K) icms_dc=5 , 0.0593692 secs] [Times: user=0.18 > sys=0.06, real=0.06 secs] > 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: > 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 > sys=0.06, real=4.22 secs] > I'm assuming that there was no GC activity between the ParNew collection and the initial-mark above. That says that the application has been filling up the young gen for a while. Most of that might be dead when the initial-mark starts but we don't know so we have to assume that it's live. Live objects in the young gen can keep objects alive in the tenured (cms) generation so we need to look at the young gen and your young gen is large so there's lots of GC work there. The first initial-mark had a full GC just before it (right?) so the young gen was likely empty. If you run your test case longer and see mostly longer initial-marks, that would suggest that my guess is right. > 2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start] > 2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 > secs] [Times: user=0.35 sys=0.15, real=0.06 secs] > 2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start] > 2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: > 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] > 2010-04-13T23:05:33.347+0000: 3347.129: > [CMS-concurrent-abortable-preclean-start] > CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: > [CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 > sys=0.24, real=5.11 secs] > 2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K > (16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak > refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] > 7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, > real=4.23 secs] > Also note that your remark pause is long. If you add -XX:+CMSScavengeBeforeRemark it will schedule a ParNew collection before the remark. If this causes the remark pause to drop significantly, that also suggests that the issue is just lots of work with lots of live objects in the young gen (because the ParNew collection will reduce the number of live objects in the young gen). _______________________________________________ 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 oracle.com Wed Apr 14 10:42:48 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 14 Apr 2010 10:42:48 -0700 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: <4BC5FD4F.6030506@oracle.com> References: <4BC5FD4F.6030506@oracle.com> Message-ID: <4BC5FE98.2070502@oracle.com> Right, this is a performance bug in CMS in general (init mark is single-threaded) and is exacerbated by iCMS (because of the way the init-mark is scheduled currently between scavenges so as to temporally separate pauses). Just drop the incremental option and you would be fine in this case. I'll annotate an existing bug for long init mark pauses with this info about the pathology being exacerbated by iCMS .... and see if we can fix it sooner ... -- ramki On 04/14/10 10:37, Jon Masamitsu wrote: > On 04/14/10 07:24, Matt Khan wrote: >> >> 2010-04-13T22:47:09.067+0000: 2242.850: [GC 2242.851: [ParNew >> Desired survivor size 14745600 bytes, new threshold 1 (max 1) >> - age 1: 7803368 bytes, 7803368 total >> : 16359981K->12388K(16368000K), 0.0589077 secs] >> 16363570K->24406K(16564608K) icms_dc=5 , 0.0593692 secs] [Times: user=0.18 >> sys=0.06, real=0.06 secs] >> 2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: >> 12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 >> sys=0.06, real=4.22 secs] >> > I'm assuming that there was no GC activity between the ParNew collection and > the initial-mark above. > > That says that the application has been filling up the young gen for a > while. Most of that might > be dead when the initial-mark starts but we don't know so we have to > assume that it's live. > Live objects in the young gen can keep objects alive in the tenured > (cms) generation so > we need to look at the young gen and your young gen is large so there's > lots of GC work > there. > > The first initial-mark had a full GC just before it (right?) so the > young gen was likely > empty. > > If you run your test case longer and see mostly longer initial-marks, > that would suggest > that my guess is right. >> 2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start] >> 2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 >> secs] [Times: user=0.35 sys=0.15, real=0.06 secs] >> 2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start] >> 2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: >> 0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] >> 2010-04-13T23:05:33.347+0000: 3347.129: >> [CMS-concurrent-abortable-preclean-start] >> CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: >> [CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 >> sys=0.24, real=5.11 secs] >> 2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K >> (16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak >> refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] >> 7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, >> real=4.23 secs] >> > Also note that your remark pause is long. If you add > -XX:+CMSScavengeBeforeRemark > it will schedule a ParNew collection before the remark. If this causes > the remark pause > to drop significantly, that also suggests that the issue is just lots of > work with > lots of live objects in the young gen (because the ParNew collection > will reduce the > number of live objects in the young gen). > > _______________________________________________ > 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 tony.printezis at oracle.com Wed Apr 14 11:33:56 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Apr 2010 14:33:56 -0400 Subject: Does allocation performance vary by collector? In-Reply-To: <4BC5E273.3040703@oracle.com> References: <4BC5E273.3040703@oracle.com> Message-ID: <4BC60A94.40006@oracle.com> Apart from the fact that the size of G1's regions might cap the TLAB sizes, the presence of heap regions also introduces a second slow path to the allocation code. When a thread tries to allocate a new TLAB but the current allocating region is full, it needs to "retire" the current one and grab a new one region. To increase the heap region size you can use the G1HeapRegionSize=N parameter. Currently, the allowed range is between 1m and 32m. To see what the heap region size the JVM has chosen for your app, enable -XX:+PrintHeapAtGC which will show that information. And I totally agree with Ramki that just showing averages might not be very productive and you'll be better off showing distribution statistics. Tony Y. Srinivas Ramakrishna wrote: > Hi Matt -- if you are really trying to measure pure allocation throughput > you might want to completely eliminate GC overhead by making sure > yr instrumentation collects figures over an interval during which > no GC activity intervenes. > > I would typically expect NUMA(Parallel) to be better than the rest, > but just as you stated in your example certain allocation+use patterns > could degrade performance. Other than that (except for G1 see below) > all other configurations (modulo GC overhead remarks above) should show > similar allocation performance. > > G1 uses "heap regions" which might somewhat limit TLAB growth and might > cause slightly lower allocation throughput (but not necessarily; run the > non-G1 collector with +PrintTLABStatistics to get some data on TLAB > sizes). > However, you can try to fix that by choosing a larger heap region > size in G1. (G1 cognoscenti on the list can provide more details.) > > However, I see that you are interested not just in allocation performance > but latency of yr operations in general (which is why you were concerned > with GC pause times themselves). In that case, you are right that CMS or > G1 would probably be superior if you had a large heap footprint so as to > get whole heap GC's (or at least if enough objects got promoted to old > gen so as to require the occasional full gc). Between G1 and CMS, > G1 generally provides much more regular and predictable GC pauses, > but for a truly apples-to-apples comparison you cannot assume that the > optimal heap shape for CMS is the same as that for G1. CMS needs > hand tuning and G1 finds something close to optimal (but might > occasionally > need some help) -- thus paradoxically, unless you have been careful > setting the heap shape for G1 might be suboptimal, especially if you > merely took the CMS optimal setting and used it with G1. > > If you can arrange to have nothing promoted into the > old gen ever then, provided the lifetimes of objects are not too long > (so you would spend effort copying between survivor spaces), > Parallel+NUMA > may be best, modulo the caveats about NUMA-allocator anti-patterns above. > > One final remark: rather than looking at averages or other central > measures, > i'd suggest looking at latency distribution metrics to quickly get a > handle > on what is happening, and how to tune/configure which collector for > your needs. > > -- ramki > > On 04/13/10 10:46, Matt Khan wrote: >> Hi >> >> I have been revisiting our jvm configuration with the aim of reducing >> pause times, it would be nice to be consistently down below 3ms all >> the time. The allocation behaviour of the application in question >> involves a small amount of static data on startup & then a steady >> stream of objects that have a relatively short lifespan. There are 2 >> typical lifetimes of these objects with about 75% while the remainder >> have a mean of maybe 70s but there is a quite a long tail to this so >> the typical lifetime is more like <10s. There won't be many such >> objects alive at once but there are quite a few passing through. The >> app runs on a 16 core opteron box running Solaris 10 with 6u18. >> >> Therefore I've been benching different configurations with a massive >> eden and relatively tiny tenured & trying different collectors to see >> how they perform. These params were common to each run >> >> -Xms3072m -Xmx3072m -Xmn2944m -XX:+DisableExplicitGC >> -XX:+PrintGCDetails -XX:+PrintGCDateStamps >> -XX:+PrintGCApplicationStoppedTime >> -XX:+PrintGCApplicationConcurrentTime >> -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=190 >> -XX:TargetSurvivorRatio=90 >> >> I then tried the following >> >> # Parallel Scavenge -XX:+UseParallelGC -XX:+UseParallelOldGC >> # Parallel Scavenge with NUMA >> -XX:+UseParallelGC -XX:+UseNUMA -XX:+UseParallelOldGC >> # Incremental CMS/ParNew >> -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode >> -XX:+CMSIncrementalPacing -XX:+UseParNewGC >> # G1 >> -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC >> The last two (CMS/G1) were repeated on 6u18 & 6u20b02 for >> completeness as I see there were assorted fixes to G1 in 6u20b01. >> >> I measure the time it takes to execute assorted points in my flow & >> see fairly significant differences in latencies with each collector, >> for example >> >> 1) CMS == ~380-400micros 2) Parallel + NUMA == ~400micros >> 3) Parallel == ~450micros >> 4) G1 == ~550micros >> >> The times above are taken well after the jvm has warmed up (latencies >> have stabilised, compilation activity is practically non-existent) & >> there is no significant "other" activity on the server at the time. >> The differences don't appear to be pause related as the shape of the >> distribution (around those averages) is the same, it's as if it has >> settled into quite a different steady state performance. This appears >> to be repeatable though, given the time it takes to run this sort of >> benchmark, I admit to only have seen it repeated a few times. I have >> run previous benchmarks where it repeats it 20x times (keeping GC >> constant in this case, was testing something else) without seeing >> variations that big across runs which makes me suspect the collection >> algorithm as the culprit. >> >> So the point of this relatively long setup is to ask whether there >> are theoretical reasons why the choice of garbage collection >> algorithm should vary measured latency like this? I had been working >> on the assumption that eden allocation is a "bump the pointer as you >> take it from a TLAB" type of event hence generally cheap & doesn't >> really vary by algorithm. >> >> fwiw the ParNew/CMS config is still the best one for keeping down >> pause times though the parallel one was close. The former peaks at >> intermittent pauses of 20-30ms, the latter at about 40ms. The >> Parallel + NUMA one curiously involved many fewer pauses such that >> much less time was spent paused but peaked higher (~120ms) which are >> unacceptable really. I don't really understand why that is but >> speculated that it's down to the fact that one of our key domain >> objects is allocated in a different thread to where it is primarily >> used. Is this right? >> >> If there is some other data that I should post to back up some of the >> above then pls tell me and I'll add the info if I have it (and repeat >> the test if I don't) >> Cheers >> Matt >> >> Matt Khan >> -------------------------------------------------- >> GFFX Auto Trading >> Deutsche Bank, London >> >> >> --- >> >> This e-mail may contain confidential and/or privileged information. >> If you are not the intended recipient (or have received this e-mail >> in error) please notify the sender immediately and delete this >> e-mail. Any unauthorized copying, disclosure or distribution of the >> material in this e-mail is strictly forbidden. >> >> Please refer to http://www.db.com/en/content/eu_disclosures.htm for >> additional EU corporate and regulatory disclosures. > > From andreas.kohn at fredhopper.com Wed Apr 14 12:05:19 2010 From: andreas.kohn at fredhopper.com (Andreas Kohn) Date: Wed, 14 Apr 2010 21:05:19 +0200 Subject: "Disabling Explicit GC" message in gc log with G1 collector Message-ID: <1271271919.1984.17.camel@xentros> Hi, while playing with the G1 collector I noticed that our gc logs are now filled with a "Disabling Explicit GC" message repeating quite often. This seems to be coming from g1CollectedHeap.cpp G1CollectedHeap::do_collection(). We have -XX:+DisableExplicitGC and -Xloggc enabled by default, so in a way this is pretty much expected. I've now removed the print statement there, so that the gc log becomes a bit more readable. Was there a reason that G1 logs this condition? Regards, -- Andreas From tony.printezis at oracle.com Wed Apr 14 12:21:27 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Apr 2010 15:21:27 -0400 Subject: "Disabling Explicit GC" message in gc log with G1 collector In-Reply-To: <1271271919.1984.17.camel@xentros> References: <1271271919.1984.17.camel@xentros> Message-ID: <4BC615B7.70100@oracle.com> Andreas, Thanks for bringing this up. It's most likely debugging code that we accidentally failed to remove. Apologies. I'll remove it piggy-backed on my next push. Tony Andreas Kohn wrote: > Hi, > > while playing with the G1 collector I noticed that our gc logs are now > filled with a "Disabling Explicit GC" message repeating quite often. > > This seems to be coming from g1CollectedHeap.cpp > G1CollectedHeap::do_collection(). > > We have -XX:+DisableExplicitGC and -Xloggc enabled by default, so in a > way this is pretty much expected. > > I've now removed the print statement there, so that the gc log becomes a > bit more readable. Was there a reason that G1 logs this condition? > > Regards, > -- > Andreas > > From tony.printezis at oracle.com Wed Apr 14 12:25:53 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Apr 2010 15:25:53 -0400 Subject: "Disabling Explicit GC" message in gc log with G1 collector In-Reply-To: <4BC615B7.70100@oracle.com> References: <1271271919.1984.17.camel@xentros> <4BC615B7.70100@oracle.com> Message-ID: <4BC616C1.4030400@oracle.com> PS This is the culprit, right? --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp @@ -912,11 +912,6 @@ Universe::print_heap_before_gc(); } - if (full && DisableExplicitGC) { - gclog_or_tty->print("\n\n\nDisabling Explicit GC\n\n\n"); - return; - } - assert(SafepointSynchronize::is_at_safepoint(), "should be at safepoint"); assert(Thread::current() == VMThread::vm_thread(), "should be in vm thread"); Tony Printezis wrote: > Andreas, > > Thanks for bringing this up. It's most likely debugging code that we > accidentally failed to remove. Apologies. I'll remove it piggy-backed > on my next push. > > Tony > > Andreas Kohn wrote: >> Hi, >> >> while playing with the G1 collector I noticed that our gc logs are now >> filled with a "Disabling Explicit GC" message repeating quite often. >> >> This seems to be coming from g1CollectedHeap.cpp >> G1CollectedHeap::do_collection(). >> >> We have -XX:+DisableExplicitGC and -Xloggc enabled by default, so in a >> way this is pretty much expected. >> I've now removed the print statement there, so that the gc log becomes a >> bit more readable. Was there a reason that G1 logs this condition? >> Regards, >> -- >> Andreas >> >> From andreas.kohn at fredhopper.com Wed Apr 14 12:33:16 2010 From: andreas.kohn at fredhopper.com (Andreas Kohn) Date: Wed, 14 Apr 2010 21:33:16 +0200 Subject: "Disabling Explicit GC" message in gc log with G1 collector In-Reply-To: <4BC616C1.4030400@oracle.com> References: <1271271919.1984.17.camel@xentros> <4BC615B7.70100@oracle.com> <4BC616C1.4030400@oracle.com> Message-ID: <1271273596.8664.1.camel@tiamaria.ams.fredhopper.com> On Wed, 2010-04-14 at 15:25 -0400, Tony Printezis wrote: > PS This is the culprit, right? Yes. I wasn't sure whether the return there is important, so locally i only killed the print() to be safe :) Thanks for picking this up! -- Andreas > > --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > @@ -912,11 +912,6 @@ > Universe::print_heap_before_gc(); > } > > - if (full && DisableExplicitGC) { > - gclog_or_tty->print("\n\n\nDisabling Explicit GC\n\n\n"); > - return; > - } > - > assert(SafepointSynchronize::is_at_safepoint(), "should be at > safepoint"); > assert(Thread::current() == VMThread::vm_thread(), "should be in vm > thread"); > > > > Tony Printezis wrote: > > Andreas, > > > > Thanks for bringing this up. It's most likely debugging code that we > > accidentally failed to remove. Apologies. I'll remove it piggy-backed > > on my next push. > > > > Tony > > > > Andreas Kohn wrote: > >> Hi, > >> > >> while playing with the G1 collector I noticed that our gc logs are now > >> filled with a "Disabling Explicit GC" message repeating quite often. > >> > >> This seems to be coming from g1CollectedHeap.cpp > >> G1CollectedHeap::do_collection(). > >> > >> We have -XX:+DisableExplicitGC and -Xloggc enabled by default, so in a > >> way this is pretty much expected. > >> I've now removed the print statement there, so that the gc log becomes a > >> bit more readable. Was there a reason that G1 logs this condition? > >> Regards, > >> -- > >> Andreas > >> > >> -- Never attribute to malice that which can be adequately explained by stupidity. -- Hanlon's Razor -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/08917126/attachment.bin From tony.printezis at oracle.com Wed Apr 14 12:33:57 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Apr 2010 15:33:57 -0400 Subject: "Disabling Explicit GC" message in gc log with G1 collector In-Reply-To: <1271273596.8664.1.camel@tiamaria.ams.fredhopper.com> References: <1271271919.1984.17.camel@xentros> <4BC615B7.70100@oracle.com> <4BC616C1.4030400@oracle.com> <1271273596.8664.1.camel@tiamaria.ams.fredhopper.com> Message-ID: <4BC618A5.6080807@oracle.com> And of course the return is important... duh! Andreas Kohn wrote: > On Wed, 2010-04-14 at 15:25 -0400, Tony Printezis wrote: > >> PS This is the culprit, right? >> > > Yes. I wasn't sure whether the return there is important, so locally i > only killed the print() to be safe :) > > Thanks for picking this up! > > -- > Andreas > > >> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> @@ -912,11 +912,6 @@ >> Universe::print_heap_before_gc(); >> } >> >> - if (full && DisableExplicitGC) { >> - gclog_or_tty->print("\n\n\nDisabling Explicit GC\n\n\n"); >> - return; >> - } >> - >> assert(SafepointSynchronize::is_at_safepoint(), "should be at >> safepoint"); >> assert(Thread::current() == VMThread::vm_thread(), "should be in vm >> thread"); >> >> >> >> Tony Printezis wrote: >> >>> Andreas, >>> >>> Thanks for bringing this up. It's most likely debugging code that we >>> accidentally failed to remove. Apologies. I'll remove it piggy-backed >>> on my next push. >>> >>> Tony >>> >>> Andreas Kohn wrote: >>> >>>> Hi, >>>> >>>> while playing with the G1 collector I noticed that our gc logs are now >>>> filled with a "Disabling Explicit GC" message repeating quite often. >>>> >>>> This seems to be coming from g1CollectedHeap.cpp >>>> G1CollectedHeap::do_collection(). >>>> >>>> We have -XX:+DisableExplicitGC and -Xloggc enabled by default, so in a >>>> way this is pretty much expected. >>>> I've now removed the print statement there, so that the gc log becomes a >>>> bit more readable. Was there a reason that G1 logs this condition? >>>> Regards, >>>> -- >>>> Andreas >>>> >>>> >>>> > > From tony.printezis at oracle.com Wed Apr 14 12:38:01 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Apr 2010 15:38:01 -0400 Subject: "Disabling Explicit GC" message in gc log with G1 collector In-Reply-To: <4BC618A5.6080807@oracle.com> References: <1271271919.1984.17.camel@xentros> <4BC615B7.70100@oracle.com> <4BC616C1.4030400@oracle.com> <1271273596.8664.1.camel@tiamaria.ams.fredhopper.com> <4BC618A5.6080807@oracle.com> Message-ID: <4BC61999.6070909@oracle.com> PS This will go in piggy-backed on 6939027: G1: assertion failure during the concurrent phase of cleanup Now, I have to calm down and be less "trigger happy" in removing code in the future... :-) Tony Tony Printezis wrote: > And of course the return is important... duh! > > Andreas Kohn wrote: >> On Wed, 2010-04-14 at 15:25 -0400, Tony Printezis wrote: >> >>> PS This is the culprit, right? >>> >> >> Yes. I wasn't sure whether the return there is important, so locally i >> only killed the print() to be safe :) >> >> Thanks for picking this up! >> >> -- >> Andreas >> >> >>> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>> @@ -912,11 +912,6 @@ >>> Universe::print_heap_before_gc(); >>> } >>> >>> - if (full && DisableExplicitGC) { >>> - gclog_or_tty->print("\n\n\nDisabling Explicit GC\n\n\n"); >>> - return; >>> - } >>> - >>> assert(SafepointSynchronize::is_at_safepoint(), "should be at >>> safepoint"); >>> assert(Thread::current() == VMThread::vm_thread(), "should be in >>> vm thread"); >>> >>> >>> >>> Tony Printezis wrote: >>> >>>> Andreas, >>>> >>>> Thanks for bringing this up. It's most likely debugging code that >>>> we accidentally failed to remove. Apologies. I'll remove it >>>> piggy-backed on my next push. >>>> >>>> Tony >>>> >>>> Andreas Kohn wrote: >>>> >>>>> Hi, >>>>> >>>>> while playing with the G1 collector I noticed that our gc logs are >>>>> now >>>>> filled with a "Disabling Explicit GC" message repeating quite often. >>>>> >>>>> This seems to be coming from g1CollectedHeap.cpp >>>>> G1CollectedHeap::do_collection(). >>>>> >>>>> We have -XX:+DisableExplicitGC and -Xloggc enabled by default, so >>>>> in a >>>>> way this is pretty much expected. >>>>> I've now removed the print statement there, so that the gc log >>>>> becomes a >>>>> bit more readable. Was there a reason that G1 logs this condition? >>>>> Regards, >>>>> -- >>>>> Andreas >>>>> >>>>> >> >> From matt.khan at db.com Wed Apr 14 13:23:26 2010 From: matt.khan at db.com (Matt Khan) Date: Wed, 14 Apr 2010 21:23:26 +0100 Subject: Does allocation performance vary by collector? In-Reply-To: <4BC60A94.40006@oracle.com> Message-ID: >> And I totally agree with Ramki that just showing averages might not be very productive and you'll be better off showing distribution statistics. I do have distributions (I output a centile distribution basically) but am quoting averages because a) I'm not sure what an easy way to distribute this information is over a mailing list, and b) there is a consistent pattern around the quoted mean with respect to b), the distribution for each looks very much the same except the average is shifted... it's reasonably tight around the mean given the hardware we run on (typically +/- 100 micros for 90% then a bit of a tail but not tragic if no STW pauses). >> To increase the heap region size you can use the G1HeapRegionSize=N parameter. Currently, the allowed range is between 1m and 32m. is there a guide to G1 tuning anywhere? I haven't come across one hence why I've used default values (and perhaps why we appear unable to get it as fast as cms). >> modulo the caveats about NUMA-allocator anti-patterns above. I intend to change our main case that shows no gain with a NUMA-allocator so that the longer lived object is created in the thread that uses it so will repeat the bench at that point. Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/59392d0d/attachment.html From matt.khan at db.com Wed Apr 14 14:15:27 2010 From: matt.khan at db.com (Matt Khan) Date: Wed, 14 Apr 2010 22:15:27 +0100 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: <4BC5FD4F.6030506@oracle.com> Message-ID: >> The first initial-mark had a full GC just before it (right?) so the young gen was likely empty. that's right >> If you run your test case longer and see mostly longer initial-marks, that would suggest that my guess is right. the young gen is definitely not empty when the 2nd initial mark was triggered. There has been no further CMS activity since then so approaching 24hrs now, occupation of tenured has hovered ~30MB all day. I still don't understand *why* the 2nd initial mark happened. I thought CMS was only triggered once the occupation passed the threshold (IIRC this is 50% by default), since occupation was actually more like 10% or so then why did it even feel the need to do anything at all? >> If you add -XX:+CMSScavengeBeforeRemark it will schedule a ParNew collection before the remark. slightly naive Q.... why isn't this default behaviour? is it because a "normal" heap has a bigger tenured than eden hence the cost isn't skewed in the way I have it configured? >> Just drop the incremental option and you would be fine in this case. I'll give that a try and report back. Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/1b7657a0/attachment-0001.html -------------- next part -------------- _______________________________________________ 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 oracle.com Wed Apr 14 14:58:18 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 14 Apr 2010 14:58:18 -0700 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: References: Message-ID: <4BC63A7A.8010908@oracle.com> On 04/14/10 14:15, Matt Khan wrote: > . ... > > > I still don't understand *why* the 2nd initial mark happened. I > thought CMS was only triggered once the occupation passed the > threshold (IIRC this is 50% by default), since occupation was actually > more like 10% or so then why did it even feel the need to do anything > at all? > CMS tries to project how early to start a cycle based on past behavior. When there hasn't been much data gathered about collections, the projection can just be wrong. > >> If you add -XX:+CMSScavengeBeforeRemark it will schedule a ParNew > collection before the remark. > slightly naive Q.... why isn't this default behaviour? is it because a > "normal" heap has a bigger tenured than eden hence the cost isn't > skewed in the way I have it configured? That would put a young gen collection and a remark back-to-back and users see it as a single longer pause. We work to keep space between those two pauses. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/dd4d0116/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From matt.khan at db.com Wed Apr 14 15:31:29 2010 From: matt.khan at db.com (Matt Khan) Date: Wed, 14 Apr 2010 23:31:29 +0100 Subject: Avoiding 1 long CMS with a big heap In-Reply-To: <4BC63A7A.8010908@oracle.com> Message-ID: >> CMS tries to project how early to start a cycle based on past behavior. When there hasn't been much data gathered about collections, the projection can just be wrong. OK so it seems to be Q of how can I mitigate this risk, i.e. is there anything I can do to influence this behaviour such that the probability of such an incorrect call, by the collector, is reduced? Obviously ideally it would be possible to eliminate the risk full stop but based on your reply it sounds like I'd need to be able to guarantee that "this object really is not reachable by anything that's in tenured" which really appears to equate to explicit memory management. Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/bbd3601f/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Ciciora at cboe.com Thu Apr 15 12:09:03 2010 From: Ciciora at cboe.com (Ciciora, Paul) Date: Thu, 15 Apr 2010 14:09:03 -0500 Subject: hotspot-gc-dev Digest, Vol 34, Issue 13 Message-ID: <8CDFE9CE1B9A344E9AA47C27B7C58DD8024517D9@MSMAIL.cboent.cboe.com> For what its worth there is a -XX to initiate only on Occupancy fraction. I want to say its CMSInitiatingOccupancyOnly. ----- Original Message ----- From: hotspot-gc-dev-bounces at openjdk.java.net To: hotspot-gc-dev at openjdk.java.net Sent: Thu Apr 15 14:00:04 2010 Subject: hotspot-gc-dev Digest, Vol 34, Issue 13 Send hotspot-gc-dev mailing list submissions to hotspot-gc-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev or, via email, send a message with subject or body 'help' to hotspot-gc-dev-request at openjdk.java.net You can reach the person managing the list at hotspot-gc-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of hotspot-gc-dev digest..." Today's Topics: 1. Re: Avoiding 1 long CMS with a big heap (Jon Masamitsu) 2. Re: Avoiding 1 long CMS with a big heap (Matt Khan) ---------------------------------------------------------------------- Message: 1 Date: Wed, 14 Apr 2010 14:58:18 -0700 From: Jon Masamitsu Subject: Re: Avoiding 1 long CMS with a big heap To: Matt Khan Cc: hotspot-gc-use at openjdk.java.net Message-ID: <4BC63A7A.8010908 at oracle.com> Content-Type: text/plain; charset="iso-8859-1" On 04/14/10 14:15, Matt Khan wrote: > . ... > > > I still don't understand *why* the 2nd initial mark happened. I > thought CMS was only triggered once the occupation passed the > threshold (IIRC this is 50% by default), since occupation was actually > more like 10% or so then why did it even feel the need to do anything > at all? > CMS tries to project how early to start a cycle based on past behavior. When there hasn't been much data gathered about collections, the projection can just be wrong. > >> If you add -XX:+CMSScavengeBeforeRemark it will schedule a ParNew > collection before the remark. > slightly naive Q.... why isn't this default behaviour? is it because a > "normal" heap has a bigger tenured than eden hence the cost isn't > skewed in the way I have it configured? That would put a young gen collection and a remark back-to-back and users see it as a single longer pause. We work to keep space between those two pauses. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/dd4d0116/attachment-0001.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use ------------------------------ Message: 2 Date: Wed, 14 Apr 2010 23:31:29 +0100 From: Matt Khan Subject: Re: Avoiding 1 long CMS with a big heap To: jon.masamitsu at oracle.com Cc: hotspot-gc-use at openjdk.java.net Message-ID: Content-Type: text/plain; charset="us-ascii" >> CMS tries to project how early to start a cycle based on past behavior. When there hasn't been much data gathered about collections, the projection can just be wrong. OK so it seems to be Q of how can I mitigate this risk, i.e. is there anything I can do to influence this behaviour such that the probability of such an incorrect call, by the collector, is reduced? Obviously ideally it would be possible to eliminate the risk full stop but based on your reply it sounds like I'd need to be able to guarantee that "this object really is not reachable by anything that's in tenured" which really appears to equate to explicit memory management. Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/bbd3601f/attachment-0001.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use End of hotspot-gc-dev Digest, Vol 34, Issue 13 ********************************************** From jon.masamitsu at oracle.com Thu Apr 15 15:51:52 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 15 Apr 2010 15:51:52 -0700 Subject: understanding GC logs In-Reply-To: <4BC62595.2000002@alcatel-lucent.com> References: <4AC0EEAE.5010705@Sun.COM> <4AC145AE.30804@sun.com> <4AC148B6.7010608@Sun.COM> <4AC1493A.2030004@sun.com> <4B4B3ECB.5090105@alcatel-lucent.com> <4B4B937C.4080907@alcatel-lucent.com> <4B4B9FBC.4040103@sun.com> <4B4BA6AF.5080300@sun.com> <4B50C9BF.8060202@alcatel-lucent.com> <4B50DE95.4060901@Sun.COM> <4BABA011.7020801@alcatel-lucent.com> <4BB20B1C.4020608@alcatel-lucent.com> <148A7A57-B616-4CA4-9571-0F0216B0F650@oracle.com> <4BC62595.2000002@alcatel-lucent.com> Message-ID: <4BC79888.5020606@oracle.com> Shaun, I'm going to answer over several replies. Here are the first 2 answers. On 04/14/10 13:29, Shaun Hennessy wrote: > Still working on log output w/ different releases / log options, > but a few other follow up questions on the substance > >>> >>> - Promotion Failure >>> 4896.478: [GC 4896.478: [ParNew: 4894353K->587864K(5017600K), >>> 0.4789909 secs] 8473688K->4268560K(13619200K), 0.4791812 secs] >>> [Times: user=1.00 sys=0.61, real=0.48 secs] >>> 4897.812: [GC 4897.812: [ParNew: 4888664K->545903K(5017600K), >>> 0.4105613 secs] 8569360K->4326583K(13619200K), 0.4107560 secs] >>> [Times: user=1.06 sys=0.55, real=0.41 secs] >>> 4899.057: [GC 4899.058: [ParNew: 4846703K->638966K(5017600K), >>> 0.2759734 secs] 8627383K->4496987K(13619200K), 0.2761637 secs] >>> [Times: user=1.13 sys=0.36, real=0.28 secs] >>> 4900.101: [GC 4900.101: [ParNew: 4939768K->630721K(5017600K), >>> 0.5117751 secs] 8797789K->4607020K(13619200K), 0.5119662 secs] >>> [Times: user=0.84 sys=0.66, real=0.51 secs] >>> 4900.615: [GC 4900.615: [ParNew: 651487K->487288K(5017600K), >>> 0.0780183 secs] 4627786K->4463587K(13619200K), 0.0781687 secs] >>> [Times: user=0.96 sys=0.00, real=0.08 secs] >>> *4901.581: [GC 4901.581: [ParNew (promotion failed): >>> 4788088K->4780999K(5017600K), 2.8947499 secs]4904.476: [CMS: >>> 4003090K->1530872K(8601600K), 7.5122451 secs] >>> 8764387K->1530872K(13619200K), [CMS Perm : >>> 671102K->671102K(819200K)], 10.4072102 secs] [Times: user=11.03 >>> sys=1.09, real=10.41 secs]* >>> 4913.024: [GC 4913.024: [ParNew: 4300800K->316807K(5017600K), >>> 0.0615917 secs] 5831672K->1847679K(13619200K), 0.0617857 secs] >>> [Times: user=0.74 sys=0.00, real=0.06 secs] >>> 4914.015: [GC 4914.015: [ParNew: 4617607K->475077K(5017600K), >>> 0.0771389 secs] 6148479K->2005949K(13619200K), 0.0773290 secs] >>> [Times: user=0.95 sys=0.00, real=0.08 secs] >>> 4914.908: [GC 4914.908: [ParNew: 4775877K->586339K(5017600K), >>> 0.0857102 secs] 6306749K->2117211K(13619200K), 0.0859046 secs] >>> [Times: user=1.06 sys=0.00, real=0.09 secs] >>> 4915.816: [GC 4915.816: [ParNew: 4887139K->476398K(5017600K), >>> 0.1841627 secs] 6418011K->2152868K(13619200K), 0.1843556 secs] >>> [Times: user=1.32 sys=0.07, real=0.18 secs] >> >>> 8) What exactly is occurring during this promotion failed >>> collection? Based on the next example I assume >>> it's a (successful) scavenge. What exactly is this - which >>> thread(s) serial / ParallelGCThreads?, >>> STW?, are we simply compacting the tenured gen or are we can >>> actually GC the tenured? >> >> A promotion failure is a scavenge that does not succeed because there >> is not enough >> space in the old gen to do all the needed promotions. The scavenge >> is in essence >> unwound and then a full STW compaction of the entire heap is done. > 1) Just so I am clear "compaction" is compacting of the heap (making a > contiguous heap) AND > garbage collection at the same time? -- the "CMS: > 4003090K->1530872K(8601600K)" > shows me my total heap is 1.5GB following this action, whereas the > previous ParNew showed total heap was at 4.4GB. "compaction" is a feature of some garbage collectors and in this case, a garbage collection with compaction is happening. > > > 2) Also just noticed this, what is the reason for the previous minor > collection ? > 4900.615 [ParNew: 651487K->487288K(5017600K) --> Normally the > minors are > at 4.8GB and get reduced to about 600K, whereas this one started at > 650K. > Using survivor isn't impacting/changing anything is it? > > Maybe it's because at 4900.615 we finished at 487K and than less than > 1 second later at 4901.581 we have a another ParNew (the failure) and the > 4788088K->4780999K entry --- so in less than 1 second we allocated 4GB. > So perhaps does this answer my previous question about why a minor comes > along at only 651K - we're trying to allocate a 4GB object / 4GB worth > of large objects? > I guess this explains why I had a promotion failure / confirms > fragmentation > despite having more than 4GB free in tenured I probably didn't 4GB > contiguous. Hard to say why the collection with only 651487k used. You're using JNI critical sections which affects garbage collection so something could be going wrong with that interaction. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100415/23bbd60f/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.cuthbertson at sun.com Thu Apr 15 17:57:24 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Fri, 16 Apr 2010 00:57:24 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6943926: G1: Integer overflow during heap region verification Message-ID: <20100416005727.C23E244584@hg.openjdk.java.net> Changeset: 5dbd9300cf9c Author: johnc Date: 2010-04-15 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5dbd9300cf9c 6943926: G1: Integer overflow during heap region verification Summary: The expression that calculates the live bytes for a heap region can overflow for a suitably large humongous region/object. Cache the object size in a suitably sized local variable so that the expression is converted to a wider type. Reviewed-by: tonyp, jmasa, iveresov, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From tony.printezis at oracle.com Fri Apr 16 00:20:07 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 16 Apr 2010 07:20:07 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6939027: G1: assertion failure during the concurrent phase of cleanup Message-ID: <20100416072010.BD9FD44597@hg.openjdk.java.net> Changeset: f9ec1e4bbb44 Author: tonyp Date: 2010-04-15 18:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f9ec1e4bbb44 6939027: G1: assertion failure during the concurrent phase of cleanup Summary: The outgoing region map is not maintained properly and it's causing an assert failure. Given that we don't actually use it, I'm removing it. I'm piggy-backing a small change on this which removes a message that it's printed before a Full GC when DisableExplicitGC is set. Reviewed-by: apetrusenko, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp From jon.masamitsu at oracle.com Fri Apr 16 11:03:11 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 16 Apr 2010 11:03:11 -0700 Subject: understanding GC logs In-Reply-To: <4BC62595.2000002@alcatel-lucent.com> References: <4AC0EEAE.5010705@Sun.COM> <4AC145AE.30804@sun.com> <4AC148B6.7010608@Sun.COM> <4AC1493A.2030004@sun.com> <4B4B3ECB.5090105@alcatel-lucent.com> <4B4B937C.4080907@alcatel-lucent.com> <4B4B9FBC.4040103@sun.com> <4B4BA6AF.5080300@sun.com> <4B50C9BF.8060202@alcatel-lucent.com> <4B50DE95.4060901@Sun.COM> <4BABA011.7020801@alcatel-lucent.com> <4BB20B1C.4020608@alcatel-lucent.com> <148A7A57-B616-4CA4-9571-0F0216B0F650@oracle.com> <4BC62595.2000002@alcatel-lucent.com> Message-ID: <4BC8A65F.40408@oracle.com> On 4/14/10 1:29 PM, Shaun Hennessy wrote: > ... > >> >>> >>> >>> >>> promotion failed, and full GC >>> 50786.124: [GC 50786.124: [ParNew: 4606713K->338518K(5017600K), >>> 0.0961884 secs] 12303455K->8081859K(13619200K), 0.0963907 secs] >>> [Times: user=0.91 sys=0.01, real=0.10 secs] >>> 50787.373: [GC 50787.373: [ParNew: 4639318K->272229K(5017600K), >>> 0.0749353 secs] 12382659K->8053730K(13619200K), 0.0751408 secs] >>> [Times: user=0.75 sys=0.00, real=0.08 secs] >>> 50788.483: [GC 50788.483: [ParNew: 4573029K->393397K(5017600K), >>> 0.0837182 secs] 12354530K->8185595K(13619200K), 0.0839321 secs] >>> [Times: user=1.03 sys=0.00, real=0.08 secs] >>> 50789.590: [GC 50789.590: [ParNew (promotion failed): >>> 4694264K->4612345K(5017600K), 1.5974678 secs] >>> 12486461K->12447305K(13619200K), 1.5976765 secs] [Times : user=2.38 >>> sys=0.20, real=1.60 secs] >>> GC locker: Trying a full collection because scavenge failed >>> 50791.188: [Full GC 50791.188: [CMS: 7834959K->1227325K(8601600K), >>> 6.7102106 secs] 12447305K->1227325K(13619200K), [CMS Perm : >>> 670478K->670478K(819200K)], 6.7103417 secs] [Times: user=6.71 >>> sys=0.00, real=6.71 secs] >>> 50798.982: [GC 50798.982: [ParNew: 4300800K->217359K(5017600K), >>> 0.0364557 secs] 5528125K->1444685K(13619200K), 0.0366630 secs] >>> [Times: user=0.44 sys=0.00, real=0.04 secs] >>> 50800.246: [GC 50800.246: [ParNew: 4518167K->198753K(5017600K), >>> 0.0368620 secs] 5745493K->1426078K(13619200K), 0.0370604 secs] >>> [Times: user=0.46 sys=0.01, real=0.04 secs] >>> 9) Probably once I understand what the scavenge is doing will help >>> me understand this case, but logic seems >>> simply enough - fullgc on promotionfailure&scavenge failed. >> >> Yes, full STW compaction. >> > 3) So in the prevous case (promotion failed) you said it was "full > STW compaction of the entire heap is done" and > here in the (promotion failed; GC locker; Full GC) also "full STW > compaction" --- what is the difference between > the 2 scenarios (ie cause and effect)? From below your "/The "GC > locker" message says that after a JNI critical > section was exited the GC wanted to do a scavenge but did not think > there was enough room in the old gen so it > does a full STW compaction." -- /so the cause of the difference > between the 2 cases is simply the fact the tenured > generation was more full in this latest case? So in terms of > effect -- is anything different actually > being done regarding the between the 2 cases or is just the log > messages being displayed are different - but they > are the exact same type of GC? > The collections are the same (both full STW compactions). The only difference are the circumstances under which the GC were done. JNI critical sections can temporarily delay a GC and whenthe critical section is exited the delayed GC happens. That's about all I know about that. > > 4) Forgetting these specific examples, if we are having > frequent/troublesome promotion failures > is there anything beyond Those are the usual remedies. I suppose you could also try to reduce the amount of allocations you do. > > a) Try 6u20 > b) Try a lower InitiatingOccupancy > c) Try a smaller Eden Gen & bigger Tenured / or simply bigger Heap > - Does the use of Survivor Space vs not using Survivor make it more or > less likely to have promotion failures? Having survivor spaces are better in general. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100416/49f446f0/attachment-0001.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From andrey.petrusenko at sun.com Fri Apr 16 13:18:04 2010 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 16 Apr 2010 20:18:04 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6942253: G1: replace G1ParallelGCAllocBufferSize with YoungPLABSize and OldPLABSize Message-ID: <20100416201807.B726B445BF@hg.openjdk.java.net> Changeset: 79e419e5ea3b Author: apetrusenko Date: 2010-04-16 08:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/79e419e5ea3b 6942253: G1: replace G1ParallelGCAllocBufferSize with YoungPLABSize and OldPLABSize Summary: Replaces the G1-specific parameter with the existing ones that are used by the other GCs (YoungPLABSize and OldPLABSize) Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp From john.coomes at oracle.com Fri Apr 16 13:31:21 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 20:31:21 +0000 Subject: hg: jdk7/hotspot-gc: 7 new changesets Message-ID: <20100416203121.ADCE5445C1@hg.openjdk.java.net> Changeset: bbd817429100 Author: jjg Date: 2010-03-12 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/bbd817429100 6934712: run langtools jtreg tests from top level test/Makefile Reviewed-by: ohair ! test/Makefile Changeset: c60ed0f6d91a Author: ohair Date: 2010-03-12 17:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/c60ed0f6d91a 6934759: Add langtools testing to jprt control builds Reviewed-by: jjg ! make/jprt.properties Changeset: 98505d97a822 Author: lana Date: 2010-03-18 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/98505d97a822 Merge Changeset: 35d272ef7598 Author: ohair Date: 2010-03-19 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/35d272ef7598 6936788: Minor adjustment to top repo test/Makefile, missing non-zero exit case Reviewed-by: jjg ! test/Makefile Changeset: b1c3b0e44b9d Author: lana Date: 2010-04-08 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/b1c3b0e44b9d Merge Changeset: 7f1ba4459972 Author: lana Date: 2010-04-13 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/7f1ba4459972 Merge Changeset: 425ba3efabbf Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/425ba3efabbf Added tag jdk7-b89 for changeset 7f1ba4459972 ! .hgtags From john.coomes at oracle.com Fri Apr 16 13:31:27 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 20:31:27 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b89 for changeset bb4424c5e778 Message-ID: <20100416203130.EFA69445C2@hg.openjdk.java.net> Changeset: 56ce07b0eb47 Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/56ce07b0eb47 Added tag jdk7-b89 for changeset bb4424c5e778 ! .hgtags From john.coomes at oracle.com Fri Apr 16 13:36:08 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 20:36:08 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b89 for changeset d2818fd2b036 Message-ID: <20100416203608.64E38445C3@hg.openjdk.java.net> Changeset: c5d932ee326d Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/c5d932ee326d Added tag jdk7-b89 for changeset d2818fd2b036 ! .hgtags From john.coomes at oracle.com Fri Apr 16 13:36:13 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 20:36:13 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b89 for changeset bf3675aa7f20 Message-ID: <20100416203613.CD324445C4@hg.openjdk.java.net> Changeset: ead7c4566a00 Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/ead7c4566a00 Added tag jdk7-b89 for changeset bf3675aa7f20 ! .hgtags From john.coomes at oracle.com Fri Apr 16 13:40:16 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 20:40:16 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 77 new changesets Message-ID: <20100416210442.01700445C5@hg.openjdk.java.net> Changeset: 0137b5857c63 Author: okutsu Date: 2010-03-10 14:32 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0137b5857c63 6932473: (tz) javazic produces incorrect SimpleTimeZone parameters with Sun<=7 Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/RuleDay.java Changeset: 0e0ce1aa1bba Author: peytoia Date: 2010-03-11 11:54 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0e0ce1aa1bba 6933032: (tz) Support tzdata2010e Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/southamerica Changeset: ce3770eadf85 Author: malenkov Date: 2010-03-11 17:39 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ce3770eadf85 6707226: java.beans.Statement & java.beans.Expression miss one important usecase Reviewed-by: rupashka ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Statement/Test6707226.java Changeset: d86c053ca938 Author: rupashka Date: 2010-03-15 16:16 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d86c053ca938 6931347: SynthTabbedPaneUI.paintTabArea() is not called when tabbed pane is painted Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: 1224c1388e86 Author: rupashka Date: 2010-03-17 12:48 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1224c1388e86 6933784: NIMBUS: ImageView getNoImageIcon and getLoadingImageIcon returns nulls instead of an icon Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java + test/javax/swing/plaf/synth/Test6933784.java Changeset: ac4c8e3bf93f Author: lana Date: 2010-03-17 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ac4c8e3bf93f Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: 325823a26aac Author: peterz Date: 2010-03-18 12:02 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/325823a26aac 6932524: NIMBUS: 3 constructors of JSplitPane creates new jsp with continuous layout - they should not. Reviewed-by: alexp ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/plaf/nimbus/skin.laf Changeset: ef892cd084ec Author: rupashka Date: 2010-03-24 15:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ef892cd084ec 6922214: SynthTextPaneUI.installUI() doesn't install the default caret and highlighter Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java Changeset: f799c62ad4f8 Author: peytoia Date: 2010-03-30 18:35 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f799c62ad4f8 6939021: (tz) Support tzdata2010g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java Changeset: dbde35ddda78 Author: peytoia Date: 2010-03-30 21:16 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dbde35ddda78 6907881: Different undesired behavior for entering Asian characters in Windows IME starting with Java 6.0 Reviewed-by: okutsu ! src/windows/native/sun/windows/awt_Component.cpp Changeset: eb39ccbd95f9 Author: lana Date: 2010-04-08 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/eb39ccbd95f9 Merge Changeset: d23dcd3e3ce4 Author: andrew Date: 2010-03-12 01:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d23dcd3e3ce4 6934327: Update linux fontconfigs for Ubuntu and Fedora. Summary: Use fontconfigs suitable for recent Fedora, Ubuntu and Debian releases. Reviewed-by: prr ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties Changeset: 45bd445f6250 Author: lana Date: 2010-03-19 18:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/45bd445f6250 Merge - make/java/text/FILES_java.gmk - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: bf23bec88222 Author: lana Date: 2010-04-08 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bf23bec88222 Merge Changeset: 47958f76babc Author: chegar Date: 2010-03-10 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/47958f76babc 6933618: java/net/MulticastSocket/NoLoopbackPackets.java fails when rerun Reviewed-by: alanb ! test/java/net/MulticastSocket/NoLoopbackPackets.java Changeset: 467484e025d6 Author: martin Date: 2010-03-10 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/467484e025d6 6931812: A better implementation of sun.nio.cs.Surrogate.isBMP(int) Summary: uc >> 16 == 0 is superior to (int) (char) uc == uc Reviewed-by: sherman Contributed-by: Ulf Zibis ! src/share/classes/sun/nio/cs/Surrogate.java Changeset: 07e1c5a90c6a Author: chegar Date: 2010-03-11 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/07e1c5a90c6a 6934054: java/net/Socket/FDClose.java return error in samevm Summary: test is no longer useful Reviewed-by: alanb ! test/ProblemList.txt - test/java/net/Socket/FDClose.java Changeset: c342735a3e58 Author: chegar Date: 2010-03-11 17:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c342735a3e58 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieHandlerTest.java Changeset: c6f8c58ed51a Author: chegar Date: 2010-03-11 17:50 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c6f8c58ed51a 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Reviewed-by: michaelm, chegar Contributed-by: damjan.jov at gmail.com ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java + test/java/net/Socket/SocksConnectTimeout.java Changeset: ee385b4e2ffb Author: sherman Date: 2010-03-11 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ee385b4e2ffb 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Summary: system property sun.zip.disableMemoryMapping to disable mmap use Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h Changeset: bf6eb240e718 Author: ohair Date: 2010-03-12 09:03 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bf6eb240e718 6933294: Fix some test/Makefile issues around Linux ARCH settings, better defaults Reviewed-by: jjg ! test/Makefile ! test/ProblemList.txt Changeset: cda90ceb7176 Author: ohair Date: 2010-03-12 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cda90ceb7176 Merge ! test/ProblemList.txt Changeset: f88f6f8ddd21 Author: chegar Date: 2010-03-16 10:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f88f6f8ddd21 6934923: test/java/net/ipv6tests/TcpTest.java hangs on Solaris 10 Reviewed-by: alanb ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java Changeset: 895a1211b2e1 Author: chegar Date: 2010-03-16 14:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/895a1211b2e1 6935199: java/net regression tests failing with Assertions Reviewed-by: michaelm ! test/ProblemList.txt ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/URLClassLoader/closetest/CloseTest.java Changeset: 0500f7306cbe Author: weijun Date: 2010-03-17 09:55 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0500f7306cbe 6868865: Test: sun/security/tools/jarsigner/oldsig.sh fails under all platforms Reviewed-by: wetmore ! test/sun/security/tools/jarsigner/oldsig.sh Changeset: 2796f839e337 Author: weijun Date: 2010-03-18 18:26 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2796f839e337 6829283: HTTP/Negotiate: Autheticator triggered again when user cancels the first one Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/spnego/NegotiateCallbackHandler.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java Changeset: c52f292a8f86 Author: valeriep Date: 2010-03-18 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c52f292a8f86 6695485: SignedObject constructor throws ProviderException if it's called using provider "SunPKCS11-Solaris" Summary: Added checking for RSA key lengths in initSign and initVerify Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Signature.java + test/sun/security/pkcs11/Signature/TestRSAKeyLength.java Changeset: df5714cbe76d Author: valeriep Date: 2010-03-18 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/df5714cbe76d 6591117: Poor preformance of PKCS#11 security provider compared to Sun default provider Summary: Added internal buffering to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java Changeset: dc42c9d9ca16 Author: valeriep Date: 2010-03-18 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dc42c9d9ca16 6837847: PKCS#11 A SecureRandom and a serialization error following installation of 1.5.0_18 Summary: Added a custom readObject method to PKCS11 SecureRandom impl Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11SecureRandom.java + test/sun/security/pkcs11/SecureRandom/TestDeserialization.java Changeset: dff4f51b73d4 Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dff4f51b73d4 Merge Changeset: 3bb93c410f41 Author: chegar Date: 2010-03-19 13:07 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3bb93c410f41 6935233: java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java fails with modules build Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java + test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh Changeset: c40572afb29e Author: chegar Date: 2010-03-22 11:55 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c40572afb29e 6632169: HttpClient and HttpsClient should not try to reverse lookup IP address of a proxy server Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java Changeset: 31dcf23042f9 Author: weijun Date: 2010-03-23 10:41 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/31dcf23042f9 6586707: NTLM authentication with proxy fails Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 8a9ebdc27045 Author: chegar Date: 2010-03-23 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8a9ebdc27045 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented" 6766775: X509 certificate hostname checking is broken in JDK1.6.0_10 Summary: All three bugs are interdependent Reviewed-by: xuelei ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java Changeset: f8c9a5e3f5db Author: dcubed Date: 2010-03-23 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f8c9a5e3f5db 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove exception throw to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/native/sun/management/Flag.c Changeset: 26477628f2d5 Author: weijun Date: 2010-03-25 12:07 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/26477628f2d5 6813340: X509Factory should not depend on is.available()==0 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/KeyTool.java + test/java/security/cert/CertificateFactory/ReturnStream.java + test/java/security/cert/CertificateFactory/SlowStream.java + test/java/security/cert/CertificateFactory/slowstream.sh Changeset: 6109b166bf68 Author: chegar Date: 2010-03-25 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6109b166bf68 6937703: java/net regression test issues with samevm Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java Changeset: 31517a0345d1 Author: xuelei Date: 2010-03-29 13:27 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/31517a0345d1 6693917: regression tests need to update for supporting ECC on solaris 11 Reviewed-by: weijun ! test/sun/security/ssl/etc/keystore ! test/sun/security/ssl/etc/truststore ! test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java Changeset: 3771ac2a8b3b Author: sherman Date: 2010-03-30 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3771ac2a8b3b 6902790: Converting/displaying HKSCs characters issue on Vista and Windows7 6911753: NSN wants to add Big5 HKSCS-2004 support Summary: support HKSCS2008 in Big5_HKSCS and MS950_HKSCS Reviewed-by: okutsu ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile + make/tools/CharsetMapping/Big5.c2b + make/tools/CharsetMapping/Big5.map + make/tools/CharsetMapping/Big5.nr + make/tools/CharsetMapping/HKSCS2001.c2b + make/tools/CharsetMapping/HKSCS2001.map + make/tools/CharsetMapping/HKSCS2008.c2b + make/tools/CharsetMapping/HKSCS2008.map + make/tools/CharsetMapping/HKSCS_XP.c2b + make/tools/CharsetMapping/HKSCS_XP.map ! make/tools/CharsetMapping/dbcs - make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/DBCS.java + make/tools/src/build/tools/charsetmapping/EUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java + make/tools/src/build/tools/charsetmapping/HKSCS.java + make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java + make/tools/src/build/tools/charsetmapping/SBCS.java + make/tools/src/build/tools/charsetmapping/Utils.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5.java ! src/share/classes/sun/io/ByteToCharBig5_HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5.java ! src/share/classes/sun/io/CharToByteBig5_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/nio/cs/ext/Big5.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS.java + src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS.java + src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/native/java/lang/java_props_md.c ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/native/java/lang/java_props_md.c ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/Charset/RegisteredCharsets.java Changeset: 1105276dbd6a Author: sherman Date: 2010-04-03 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1105276dbd6a 4947220: (process)Runtime.exec() cannot invoke applications with unicode parameters(win) Summary: to use CreateProcessW on Windowns platform Reviewed-by: martin ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! test/java/lang/ProcessBuilder/Basic.java Changeset: d3309aae68ef Author: dl Date: 2009-10-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d3309aae68ef 6888149: AtomicReferenceArray causes SIGSEGV -> SEGV_MAPERR error Summary: Avoid integer overflow by using long arithmetic Reviewed-by: martin, dholmes ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java Changeset: 08f57141c305 Author: asaha Date: 2009-11-20 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/08f57141c305 Merge - test/sun/tools/native2ascii/test2 Changeset: b1e8f41ed755 Author: chegar Date: 2009-11-23 12:40 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b1e8f41ed755 6639665: ThreadGroup finalizer allows creation of false root ThreadGroups Reviewed-by: alanb, hawtin ! src/share/classes/java/lang/ThreadGroup.java Changeset: e943f6b0b0e9 Author: alanb Date: 2009-11-25 10:02 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e943f6b0b0e9 6736390: File TOCTOU deserialization vulnerability Reviewed-by: hawtin ! src/share/classes/java/io/File.java Changeset: ff9c2f53594e Author: sherman Date: 2009-11-25 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ff9c2f53594e 6745393: Inflater/Deflater clone issue Summary: To use explicit lobk object. Reviewed-by: alanb ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c Changeset: d893f890b4dd Author: sherman Date: 2009-11-25 12:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d893f890b4dd 6904925: Changeset for 6745393 for jdk7 ssr forest was incomplete Summary: To add, commit and push back the ZStreamRef.java Reviewed-by: alanb + src/share/classes/java/util/zip/ZStreamRef.java Changeset: df3091222715 Author: mchung Date: 2009-11-25 09:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/df3091222715 6893947: Deserialization of RMIConnectionImpl objects should enforce stricter checks [ZDI-CAN-588] Summary: narrow the doPrivileged block to only set context ClassLoader Reviewed-by: hawtin, emcmanus ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: bc309e9233ce Author: mchung Date: 2009-11-25 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bc309e9233ce Merge Changeset: 621edf6b03fc Author: mchung Date: 2009-11-25 16:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/621edf6b03fc Merge Changeset: 338c8775f0a3 Author: asaha Date: 2009-11-26 07:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/338c8775f0a3 Merge Changeset: f0b63b6d9709 Author: asaha Date: 2009-12-01 08:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f0b63b6d9709 Merge - test/tools/launcher/SolarisDataModel.sh - test/tools/launcher/SolarisRunpath.sh - test/tools/launcher/libraryCaller.c - test/tools/launcher/libraryCaller.h - test/tools/launcher/libraryCaller.java Changeset: 121fa73c7185 Author: michaelm Date: 2009-12-02 12:17 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/121fa73c7185 6893954: Subclasses of InetAddress may incorrectly interpret network addresses Summary: runtime type checks and deserialization check Reviewed-by: chegar, alanb, jccollet ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/Socket.java ! src/share/classes/sun/nio/ch/Net.java Changeset: edaa7e2efd63 Author: asaha Date: 2009-12-04 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/edaa7e2efd63 Merge - make/tools/CharsetMapping/DoubleByte-X.java - make/tools/CharsetMapping/SingleByte-X.java - src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java - test/java/util/Formatter/Basic-X.java Changeset: 3598d6eb087c Author: xuelei Date: 2009-12-07 21:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3598d6eb087c 6898739: TLS renegotiation issue Summary: the interim fix disables TLS/SSL renegotiation Reviewed-by: mullan, chegar, wetmore ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java Changeset: 91a4840fa9b4 Author: mullan Date: 2009-12-08 15:58 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/91a4840fa9b4 6633872: Policy/PolicyFile leak dynamic ProtectionDomains. Reviewed-by: hawtin ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/ProtectionDomain.java + src/share/classes/sun/misc/JavaSecurityProtectionDomainAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: 7a60d100ffa5 Author: mullan Date: 2009-12-18 09:09 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7a60d100ffa5 6904162: Add new VeriSign root CA certificates to JRE and remove some old/unused ones Reviewed-by: asaha - test/lib/security/cacerts/VerifyCACerts.java Changeset: 3dabb7d5be98 Author: malenkov Date: 2009-12-22 17:56 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3dabb7d5be98 6904691: Java Applet Trusted Methods Chaining Privilege Escalation Vulnerability Reviewed-by: hawtin, peterz ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/Statement.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java Changeset: c80b6350de63 Author: michaelm Date: 2010-01-12 12:13 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c80b6350de63 6910590: Application can modify command array, in ProcessBuilder Summary: clone array returned by List.toArray() Reviewed-by: chegar, alanb ! src/share/classes/java/lang/ProcessBuilder.java Changeset: 0667ab707c48 Author: bae Date: 2010-02-17 12:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0667ab707c48 6914866: Sun JRE ImagingLib arbitrary code execution vulnerability Reviewed-by: prr, hawtin ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 494aea51f26f Author: bae Date: 2010-02-17 13:10 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/494aea51f26f 6914823: Java AWT Library Invalid Index Vulnerability Reviewed-by: flar, hawtin ! src/share/classes/sun/awt/image/ImageRepresentation.java Changeset: 45ead4a2c48b Author: bae Date: 2010-02-17 13:32 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/45ead4a2c48b 6909597: Sun Java Runtime Environment JPEGImageReader stepX Integer Overflow Vulnerability Reviewed-by: igor ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: 1ff19af7b735 Author: bae Date: 2010-02-19 22:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1ff19af7b735 6899653: Sun Java Runtime CMM readMabCurveData Buffer Overflow Vulnerability Reviewed-by: prr, hawtin ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c Changeset: cda01c4b091c Author: ksrini Date: 2010-02-22 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cda01c4b091c 6902299: Java JAR "unpack200" must verify input parameters Summary: Added several checks for addition of values before memory allocation Reviewed-by: asaha ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: 7a6b3cc68e92 Author: denis Date: 2010-02-26 03:54 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7a6b3cc68e92 6887703: Unsigned applet can retrieve the dragged information before drop action occur Reviewed-by: uta ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: c5c6f8fa92ae Author: denis Date: 2010-03-06 03:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c5c6f8fa92ae 6932659: JTreg test files were missed in push of 6887703 Reviewed-by: uta ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java Changeset: 2805db6e6ff6 Author: asaha Date: 2010-03-24 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2805db6e6ff6 Merge - make/java/redist/FILES.gmk - make/java/text/FILES_java.gmk - make/sun/nio/FILES_java.gmk ! src/share/classes/java/beans/Statement.java ! src/share/classes/java/util/zip/Deflater.java - src/share/classes/javax/swing/plaf/synth/DefaultMenuLayout.java - src/share/classes/sun/awt/ComponentAccessor.java - src/share/classes/sun/awt/WindowAccessor.java - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/share/classes/sun/security/provider/IdentityDatabase.java ! src/share/classes/sun/security/provider/PolicyFile.java - src/share/classes/sun/security/provider/SystemIdentity.java - src/share/classes/sun/security/provider/SystemSigner.java - src/share/classes/sun/security/x509/X500Signer.java - src/share/classes/sun/security/x509/X509Cert.java - src/share/classes/sun/swing/plaf/synth/SynthUI.java - src/share/classes/sun/tools/jar/JarVerifierStream.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java - test/java/net/Socket/FDClose.java Changeset: 1dccfa00dc64 Author: asaha Date: 2010-03-24 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1dccfa00dc64 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 6ec14b5ede77 Author: asaha Date: 2010-03-25 07:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6ec14b5ede77 Merge Changeset: 3ef9b3446677 Author: asaha Date: 2010-03-29 07:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3ef9b3446677 Merge Changeset: a9fdd143a58e Author: asaha Date: 2010-04-05 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a9fdd143a58e Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java Changeset: 69002275e0e2 Author: chegar Date: 2010-04-06 13:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/69002275e0e2 6648001: Cancelling HTTP authentication causes subsequent deadlocks Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/Authenticator/Deadlock.java Changeset: 495ba30cf02f Author: chegar Date: 2010-04-06 15:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/495ba30cf02f 6921111: NullPointerException in PlainDatagramSocketImpl.socketSetOption Reviewed-by: alanb ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: 0b7f10901f30 Author: sherman Date: 2010-04-06 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0b7f10901f30 6717164: FilterInputStream.skip incorrectly inherits wording specifying how the InputStream.skip works Summary: restoring the javadoc Reviewed-by: alanb ! src/share/classes/java/io/FilterInputStream.java Changeset: fc7c38b2584c Author: martin Date: 2010-04-07 12:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fc7c38b2584c 6941130: Semaphore should throw if number of permits overflows or underflows Summary: Check if release could make number of permits negative Reviewed-by: dl, dholmes ! src/share/classes/java/util/concurrent/Semaphore.java + test/java/util/concurrent/Semaphore/PermitOverflow.java Changeset: 025f9e57566a Author: lana Date: 2010-04-08 15:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/025f9e57566a Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/java/beans/Statement.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 4a6abb7e224c Author: lana Date: 2010-04-13 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4a6abb7e224c Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 7f90d0b9dbb7 Author: mikejwre Date: 2010-04-15 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7f90d0b9dbb7 Added tag jdk7-b89 for changeset 4a6abb7e224c ! .hgtags From john.coomes at oracle.com Fri Apr 16 14:22:26 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Apr 2010 21:22:26 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 10 new changesets Message-ID: <20100416212258.35D2A445C6@hg.openjdk.java.net> Changeset: 9871ce4fd56f Author: jjg Date: 2010-03-10 16:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/9871ce4fd56f 6933914: fix missing newlines Reviewed-by: ohair ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/api/6731573/Erroneous.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/varargs/T6746184.java - test/tools/javap/T6305779.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java Changeset: f856c0942c06 Author: jjg Date: 2010-03-12 12:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/f856c0942c06 6934224: update langtools/test/Makefile Reviewed-by: ohair ! make/jprt.properties ! test/Makefile Changeset: 6fad35d25b1e Author: lana Date: 2010-03-18 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/6fad35d25b1e Merge Changeset: dd30de080cb9 Author: jjg Date: 2010-03-23 18:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/dd30de080cb9 6937244: sqe ws7 tools javap/javap_t10a fail jdk7 b80 used output of javap is changed Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/6937244/T6937244.java + test/tools/javap/6937244/T6937244A.java Changeset: 3058880c0b8d Author: jjg Date: 2010-03-24 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/3058880c0b8d 6937318: jdk7 b86: javah and javah -help is no output for these commands Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java ! test/tools/javah/T6893943.java Changeset: 65e422bbb984 Author: darcy Date: 2010-03-24 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/65e422bbb984 6937417: javac -Xprint returns IndexOutOfBoundsException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + test/tools/javac/processing/model/util/elements/VacuousEnum.java Changeset: de6375751eb7 Author: ohair Date: 2010-03-26 22:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/de6375751eb7 6938326: Use of "ant -diagnostics" a problem with ant 1.8.0, exit code 1 now Reviewed-by: jjg ! make/Makefile Changeset: ad1bf317cc57 Author: lana Date: 2010-04-08 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ad1bf317cc57 Merge - test/tools/javap/T6305779.java Changeset: 6cea9a143208 Author: lana Date: 2010-04-13 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/6cea9a143208 Merge - test/tools/javap/T6305779.java Changeset: 71c2c23a7c35 Author: mikejwre Date: 2010-04-15 13:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/71c2c23a7c35 Added tag jdk7-b89 for changeset 6cea9a143208 ! .hgtags From kevin.walls at sun.com Mon Apr 19 09:23:08 2010 From: kevin.walls at sun.com (kevin.walls at sun.com) Date: Mon, 19 Apr 2010 16:23:08 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 2 new changesets Message-ID: <20100419162314.5463544608@hg.openjdk.java.net> Changeset: bdb5361c461c Author: kevinw Date: 2010-04-16 17:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bdb5361c461c 6897143: Stress test crashes during HeapInspection using ParallelGC. Summary: ensure_parsability() must be called even if GC_locker prevents GC. Reviewed-by: ysr, chrisphi ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: 6ecb6e6de3d6 Author: kevinw Date: 2010-04-19 05:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6ecb6e6de3d6 Merge From matt.khan at db.com Tue Apr 20 06:20:07 2010 From: matt.khan at db.com (Matt Khan) Date: Tue, 20 Apr 2010 14:20:07 +0100 Subject: What influences young generation pause times? Message-ID: Hi My understanding is that young gen pause times are related to the size of the set of live objects but what does this really mean? for example does it mean number of objects in the live set? total size [of them]? and what other factors influence the young gen pause time? Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100420/705d9997/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Tue Apr 20 07:04:32 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Apr 2010 10:04:32 -0400 Subject: What influences young generation pause times? In-Reply-To: References: Message-ID: <4BCDB470.8090102@oracle.com> Matt, For most applications, object copying is the predominant cost during young GCs. Basically, the more objects survive the collection and need to be copied, the higher the young GC times will be. Young GCs do not touch the dead objects in the young generation so the number of overall objects in the young generation will not really affect pause times, just the number of live ones. There are other costs during young GCs, like scanning the application thread stacks, scanning the card table to find old-to-young references, etc. However, typically, those costs are very small compared to copying the live objects. Hope this helps, Tony Matt Khan wrote: > > Hi > > My understanding is that young gen pause times are related to the size > of the set of live objects but what does this really mean? for example > does it mean number of objects in the live set? total size [of them]? > > and what other factors influence the young gen pause time? > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > --- > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. > Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. > ------------------------------------------------------------------------ > > _______________________________________________ > 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 matt.khan at db.com Tue Apr 20 09:04:08 2010 From: matt.khan at db.com (Matt Khan) Date: Tue, 20 Apr 2010 17:04:08 +0100 Subject: What influences young generation pause times? In-Reply-To: <4BCDB470.8090102@oracle.com> Message-ID: Hi Tony >> Basically, the more objects survive the collection and need to be copied, the higher the young GC times will be. so when does a concurrent collector enter a STW pause? for example if I look at figure 6, p10 in the memory management white paper (http://java.sun.com/products/hotspot/whitepaper.html) then that makes it look like there is a single STW pause per young collection that is made shorter because there are n threads doing the work. Is that an accurate depiction of when it pauses or just a convenient visualisation? My reason for asking is that my app doesn't exhibit this single pause per young collection, instead I see a succession of short pauses between GC logs (example below) & I'd like to understand what causes those pauses. This app is using CMS (params used below) but there is no CMS activity reported at this time because v little enters the tenured generation and hence there is no collection required. Total time for which application threads were stopped: 0.0051359 seconds Application time: 99.9576332 seconds 2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew Desired survivor size 14450688 bytes, new threshold 1 (max 1) - age 1: 3377144 bytes, 3377144 total : 2986668K->4491K(2998976K), 0.0254753 secs] 3076724K->94963K(3130048K) icms_dc=0 , 0.0259072 secs] [Time s: user=0.25 sys=0.01, real=0.03 secs] Total time for which application threads were stopped: 0.0330759 seconds Application time: 190.7387185 seconds Total time for which application threads were stopped: 0.0060798 seconds Application time: 9.2698867 seconds Total time for which application threads were stopped: 0.0051861 seconds Application time: 290.7195886 seconds Total time for which application threads were stopped: 0.0065455 seconds Application time: 9.2792321 seconds Total time for which application threads were stopped: 0.0051541 seconds Application time: 290.7292153 seconds Total time for which application threads were stopped: 0.0063071 seconds Application time: 9.2696694 seconds Total time for which application threads were stopped: 0.0052036 seconds Application time: 290.7093779 seconds Total time for which application threads were stopped: 0.0065365 seconds Application time: 9.2793591 seconds Total time for which application threads were stopped: 0.0051265 seconds Application time: 290.7301471 seconds Total time for which application threads were stopped: 0.0070431 seconds Application time: 9.2694376 seconds Total time for which application threads were stopped: 0.0051428 seconds Application time: 119.4074368 seconds Total time for which application threads were stopped: 0.0059739 seconds Application time: 39.8647697 seconds 2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew Desired survivor size 14450688 bytes, new threshold 1 (max 1) - age 1: 2911824 bytes, 2911824 total -Xms3072m -Xmx3072m -Xmn2944m -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=190 -XX:TargetSurvivorRatio=90 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Tue Apr 20 10:51:58 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Apr 2010 13:51:58 -0400 Subject: What influences young generation pause times? In-Reply-To: References: Message-ID: <4BCDE9BE.1070504@oracle.com> Matt, The pauses that you see seem to be non-GC safepoints. Maybe they are biased lock revocation safepoints. If the log doesn't show a [GC...] line at a safepoint, then there is not GC activity during it (at least I can't think of an occasion when this would be the case). Tony Matt Khan wrote: > Hi Tony > > >>> Basically, the more objects survive the collection and need to be >>> > copied, the higher the young GC times will be. > so when does a concurrent collector enter a STW pause? > > for example if I look at figure 6, p10 in the memory management white > paper (http://java.sun.com/products/hotspot/whitepaper.html) then that > makes it look like there is a single STW pause per young collection that > is made shorter because there are n threads doing the work. Is that an > accurate depiction of when it pauses or just a convenient visualisation? > > My reason for asking is that my app doesn't exhibit this single pause per > young collection, instead I see a succession of short pauses between GC > logs (example below) & I'd like to understand what causes those pauses. > This app is using CMS (params used below) but there is no CMS activity > reported at this time because v little enters the tenured generation and > hence there is no collection required. > > Total time for which application threads were stopped: 0.0051359 seconds > Application time: 99.9576332 seconds > 2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew > Desired survivor size 14450688 bytes, new threshold 1 (max 1) > - age 1: 3377144 bytes, 3377144 total > : 2986668K->4491K(2998976K), 0.0254753 secs] 3076724K->94963K(3130048K) > icms_dc=0 , 0.0259072 secs] [Time > s: user=0.25 sys=0.01, real=0.03 secs] > Total time for which application threads were stopped: 0.0330759 seconds > Application time: 190.7387185 seconds > Total time for which application threads were stopped: 0.0060798 seconds > Application time: 9.2698867 seconds > Total time for which application threads were stopped: 0.0051861 seconds > Application time: 290.7195886 seconds > Total time for which application threads were stopped: 0.0065455 seconds > Application time: 9.2792321 seconds > Total time for which application threads were stopped: 0.0051541 seconds > Application time: 290.7292153 seconds > Total time for which application threads were stopped: 0.0063071 seconds > Application time: 9.2696694 seconds > Total time for which application threads were stopped: 0.0052036 seconds > Application time: 290.7093779 seconds > Total time for which application threads were stopped: 0.0065365 seconds > Application time: 9.2793591 seconds > Total time for which application threads were stopped: 0.0051265 seconds > Application time: 290.7301471 seconds > Total time for which application threads were stopped: 0.0070431 seconds > Application time: 9.2694376 seconds > Total time for which application threads were stopped: 0.0051428 seconds > Application time: 119.4074368 seconds > Total time for which application threads were stopped: 0.0059739 seconds > Application time: 39.8647697 seconds > 2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew > Desired survivor size 14450688 bytes, new threshold 1 (max 1) > - age 1: 2911824 bytes, 2911824 total > > -Xms3072m > -Xmx3072m > -Xmn2944m > -XX:+DisableExplicitGC > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=190 > -XX:TargetSurvivorRatio=90 > -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > > --- > > This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. > _______________________________________________ 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 oracle.com Tue Apr 20 11:00:21 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 20 Apr 2010 11:00:21 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BCDE9BE.1070504@oracle.com> References: <4BCDE9BE.1070504@oracle.com> Message-ID: <4BCDEBB5.8030708@oracle.com> You could use -XX:+PrintSafepointStatistics etc. to figure these out. -- ramki On 04/20/10 10:51, Tony Printezis wrote: > Matt, > > The pauses that you see seem to be non-GC safepoints. Maybe they are > biased lock revocation safepoints. If the log doesn't show a [GC...] > line at a safepoint, then there is not GC activity during it (at least I > can't think of an occasion when this would be the case). > > Tony > > Matt Khan wrote: >> Hi Tony >> >> >>>> Basically, the more objects survive the collection and need to be >>>> >> copied, the higher the young GC times will be. >> so when does a concurrent collector enter a STW pause? >> >> for example if I look at figure 6, p10 in the memory management white >> paper (http://java.sun.com/products/hotspot/whitepaper.html) then that >> makes it look like there is a single STW pause per young collection that >> is made shorter because there are n threads doing the work. Is that an >> accurate depiction of when it pauses or just a convenient visualisation? >> >> My reason for asking is that my app doesn't exhibit this single pause per >> young collection, instead I see a succession of short pauses between GC >> logs (example below) & I'd like to understand what causes those pauses. >> This app is using CMS (params used below) but there is no CMS activity >> reported at this time because v little enters the tenured generation and >> hence there is no collection required. >> >> Total time for which application threads were stopped: 0.0051359 seconds >> Application time: 99.9576332 seconds >> 2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew >> Desired survivor size 14450688 bytes, new threshold 1 (max 1) >> - age 1: 3377144 bytes, 3377144 total >> : 2986668K->4491K(2998976K), 0.0254753 secs] 3076724K->94963K(3130048K) >> icms_dc=0 , 0.0259072 secs] [Time >> s: user=0.25 sys=0.01, real=0.03 secs] >> Total time for which application threads were stopped: 0.0330759 seconds >> Application time: 190.7387185 seconds >> Total time for which application threads were stopped: 0.0060798 seconds >> Application time: 9.2698867 seconds >> Total time for which application threads were stopped: 0.0051861 seconds >> Application time: 290.7195886 seconds >> Total time for which application threads were stopped: 0.0065455 seconds >> Application time: 9.2792321 seconds >> Total time for which application threads were stopped: 0.0051541 seconds >> Application time: 290.7292153 seconds >> Total time for which application threads were stopped: 0.0063071 seconds >> Application time: 9.2696694 seconds >> Total time for which application threads were stopped: 0.0052036 seconds >> Application time: 290.7093779 seconds >> Total time for which application threads were stopped: 0.0065365 seconds >> Application time: 9.2793591 seconds >> Total time for which application threads were stopped: 0.0051265 seconds >> Application time: 290.7301471 seconds >> Total time for which application threads were stopped: 0.0070431 seconds >> Application time: 9.2694376 seconds >> Total time for which application threads were stopped: 0.0051428 seconds >> Application time: 119.4074368 seconds >> Total time for which application threads were stopped: 0.0059739 seconds >> Application time: 39.8647697 seconds >> 2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew >> Desired survivor size 14450688 bytes, new threshold 1 (max 1) >> - age 1: 2911824 bytes, 2911824 total >> >> -Xms3072m >> -Xmx3072m >> -Xmn2944m >> -XX:+DisableExplicitGC >> -XX:+PrintGCDetails >> -XX:+PrintGCDateStamps >> -XX:+PrintGCApplicationStoppedTime >> -XX:+PrintGCApplicationConcurrentTime >> -XX:MaxTenuringThreshold=1 >> -XX:SurvivorRatio=190 >> -XX:TargetSurvivorRatio=90 >> -XX:+UseConcMarkSweepGC >> -XX:+UseParNewGC >> >> Cheers >> Matt >> >> Matt Khan >> -------------------------------------------------- >> GFFX Auto Trading >> Deutsche Bank, London >> >> >> >> --- >> >> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. >> >> Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. >> > _______________________________________________ > 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 tony.printezis at oracle.com Tue Apr 20 11:11:59 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Apr 2010 14:11:59 -0400 Subject: What influences young generation pause times? In-Reply-To: References: <4BCDB470.8090102@oracle.com> Message-ID: <4BCDEE6F.8030807@oracle.com> Osvaldo, You misunderstand how a copying GC (which is the algorithm our young gen GCs implement) works. It does not first mark the live objects, and then copies them. Instead, it copies the objects as it comes across them (i.e., at the same time it discovers they are live). So, there is no opportunity to find big blocks of live objects and not copy them. The end of the GC would be the only time you would be able to do that but, by then, you've already copied all the objects anyway. Regarding calling young GCs explicitly from an application: I can see how, in the case of single-threaded applications, the application might know "We are between transactions and, maybe, we have lots of garbage and not much live in the young gen. So let's do a young GC to clean up the young gen at maybe low overhead since we'll copy very little." However, how will this work in the case of multi-threaded applications, which are the vast majority of applications we see from our customers? A thread might be between transactions, but what about the other 50, 300, or even 2,000 threads? If a particular time is good to do a young GC for a particular thread, it does not mean that it's also good for the rest. Additionally, I would be willing to bet money that if we provided such an API, library writers will abuse it thinking that "hey, the end of this library call will be a great time to do a young GC!", without taking into consideration that many other threads could be doing something totally different at the same time (we've seen way too many libraries that call System.gc() already...). My two cents, Tony Osvaldo Doederlein wrote: > If you allow some intermission... is the young-gen collector smart > enough to avoid semispace copying in some favorable conditions? Let's > say I am lucky and when young-GC is triggered, after marking I have > [LLLLLLLLLLDDDD] where L=live objects, D=dead. it's stupid to copy the > block [LLLLLLLLLL] to another space. I'd expect the collector to have > some heuristic like: look at the top address and total size of the > remaining live data, and if it is densely populated (say >90% live > space - e.g. [LLLDLLLLLLDDDD]), just finish GC without any compaction > or semispace flipping. > > I would expect this scenario to happen in the real world with very > small frequency, because young-GC must be triggered at a "lucky" time, > e.g. after some application transactions commit and before any newer > transaction begins - but if the collector already accounts the live > set size at the marking phase, the cost to attempt this new > optimization is virtually zero. And we might hint the VM to make sure > the optimal case doesn't depend on good luck. The JVM could expose an > API that allows an application (or a container) to request a > "lightweight GC", i.e., perform only young-GC, and only if the > young-gen is >N% full. E.g., System.fastGC(0.8) for N=80%. A JavaEE > application server could invoke this when it detects idle periods > (zero running transactions / zero background processes doing anything > important); or even after every transaction commit if the VM uses > TLABs (in that case we only collect the TLAB; the whole thing only > makes sense for large enough TLABs). For single-threaded processes > (Ok, almost-single-threaded...) it's much simpler, just call the > lightweight-GC API at special places where major activity ends and > tons of allocated data are liberated, e.g. after the render-frame step > of your game loop, or after importing each file in your batch ETL > program, etc. > > A+ > Osvaldo > > 2010/4/20 Matt Khan > > > Hi Tony > > >> Basically, the more objects survive the collection and need to be > copied, the higher the young GC times will be. > so when does a concurrent collector enter a STW pause? > > for example if I look at figure 6, p10 in the memory management white > paper (http://java.sun.com/products/hotspot/whitepaper.html) then that > makes it look like there is a single STW pause per young > collection that > is made shorter because there are n threads doing the work. Is that an > accurate depiction of when it pauses or just a convenient > visualisation? > > My reason for asking is that my app doesn't exhibit this single > pause per > young collection, instead I see a succession of short pauses > between GC > logs (example below) & I'd like to understand what causes those > pauses. > This app is using CMS (params used below) but there is no CMS activity > reported at this time because v little enters the tenured > generation and > hence there is no collection required. > > Total time for which application threads were stopped: 0.0051359 > seconds > Application time: 99.9576332 seconds > 2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew > Desired survivor size 14450688 bytes, new threshold 1 (max 1) > - age 1: 3377144 bytes, 3377144 total > : 2986668K->4491K(2998976K), 0.0254753 secs] > 3076724K->94963K(3130048K) > icms_dc=0 , 0.0259072 secs] [Time > s: user=0.25 sys=0.01, real=0.03 secs] > Total time for which application threads were stopped: 0.0330759 > seconds > Application time: 190.7387185 seconds > Total time for which application threads were stopped: 0.0060798 > seconds > Application time: 9.2698867 seconds > Total time for which application threads were stopped: 0.0051861 > seconds > Application time: 290.7195886 seconds > Total time for which application threads were stopped: 0.0065455 > seconds > Application time: 9.2792321 seconds > Total time for which application threads were stopped: 0.0051541 > seconds > Application time: 290.7292153 seconds > Total time for which application threads were stopped: 0.0063071 > seconds > Application time: 9.2696694 seconds > Total time for which application threads were stopped: 0.0052036 > seconds > Application time: 290.7093779 seconds > Total time for which application threads were stopped: 0.0065365 > seconds > Application time: 9.2793591 seconds > Total time for which application threads were stopped: 0.0051265 > seconds > Application time: 290.7301471 seconds > Total time for which application threads were stopped: 0.0070431 > seconds > Application time: 9.2694376 seconds > Total time for which application threads were stopped: 0.0051428 > seconds > Application time: 119.4074368 seconds > Total time for which application threads were stopped: 0.0059739 > seconds > Application time: 39.8647697 seconds > 2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew > Desired survivor size 14450688 bytes, new threshold 1 (max 1) > - age 1: 2911824 bytes, 2911824 total > > -Xms3072m > -Xmx3072m > -Xmn2944m > -XX:+DisableExplicitGC > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=190 > -XX:TargetSurvivorRatio=90 > -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > > --- > > This e-mail may contain confidential and/or privileged > information. If you are not the intended recipient (or have > received this e-mail in error) please notify the sender > immediately and delete this e-mail. Any unauthorized copying, > disclosure or distribution of the material in this e-mail is > strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm > for additional EU corporate and regulatory disclosures. > _______________________________________________ > 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 opinali at gmail.com Tue Apr 20 10:27:37 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Tue, 20 Apr 2010 14:27:37 -0300 Subject: What influences young generation pause times? In-Reply-To: References: <4BCDB470.8090102@oracle.com> Message-ID: If you allow some intermission... is the young-gen collector smart enough to avoid semispace copying in some favorable conditions? Let's say I am lucky and when young-GC is triggered, after marking I have [LLLLLLLLLLDDDD] where L=live objects, D=dead. it's stupid to copy the block [LLLLLLLLLL] to another space. I'd expect the collector to have some heuristic like: look at the top address and total size of the remaining live data, and if it is densely populated (say >90% live space - e.g. [LLLDLLLLLLDDDD]), just finish GC without any compaction or semispace flipping. I would expect this scenario to happen in the real world with very small frequency, because young-GC must be triggered at a "lucky" time, e.g. after some application transactions commit and before any newer transaction begins - but if the collector already accounts the live set size at the marking phase, the cost to attempt this new optimization is virtually zero. And we might hint the VM to make sure the optimal case doesn't depend on good luck. The JVM could expose an API that allows an application (or a container) to request a "lightweight GC", i.e., perform only young-GC, and only if the young-gen is >N% full. E.g., System.fastGC(0.8) for N=80%. A JavaEE application server could invoke this when it detects idle periods (zero running transactions / zero background processes doing anything important); or even after every transaction commit if the VM uses TLABs (in that case we only collect the TLAB; the whole thing only makes sense for large enough TLABs). For single-threaded processes (Ok, almost-single-threaded...) it's much simpler, just call the lightweight-GC API at special places where major activity ends and tons of allocated data are liberated, e.g. after the render-frame step of your game loop, or after importing each file in your batch ETL program, etc. A+ Osvaldo 2010/4/20 Matt Khan > Hi Tony > > >> Basically, the more objects survive the collection and need to be > copied, the higher the young GC times will be. > so when does a concurrent collector enter a STW pause? > > for example if I look at figure 6, p10 in the memory management white > paper (http://java.sun.com/products/hotspot/whitepaper.html) then that > makes it look like there is a single STW pause per young collection that > is made shorter because there are n threads doing the work. Is that an > accurate depiction of when it pauses or just a convenient visualisation? > > My reason for asking is that my app doesn't exhibit this single pause per > young collection, instead I see a succession of short pauses between GC > logs (example below) & I'd like to understand what causes those pauses. > This app is using CMS (params used below) but there is no CMS activity > reported at this time because v little enters the tenured generation and > hence there is no collection required. > > Total time for which application threads were stopped: 0.0051359 seconds > Application time: 99.9576332 seconds > 2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew > Desired survivor size 14450688 bytes, new threshold 1 (max 1) > - age 1: 3377144 bytes, 3377144 total > : 2986668K->4491K(2998976K), 0.0254753 secs] 3076724K->94963K(3130048K) > icms_dc=0 , 0.0259072 secs] [Time > s: user=0.25 sys=0.01, real=0.03 secs] > Total time for which application threads were stopped: 0.0330759 seconds > Application time: 190.7387185 seconds > Total time for which application threads were stopped: 0.0060798 seconds > Application time: 9.2698867 seconds > Total time for which application threads were stopped: 0.0051861 seconds > Application time: 290.7195886 seconds > Total time for which application threads were stopped: 0.0065455 seconds > Application time: 9.2792321 seconds > Total time for which application threads were stopped: 0.0051541 seconds > Application time: 290.7292153 seconds > Total time for which application threads were stopped: 0.0063071 seconds > Application time: 9.2696694 seconds > Total time for which application threads were stopped: 0.0052036 seconds > Application time: 290.7093779 seconds > Total time for which application threads were stopped: 0.0065365 seconds > Application time: 9.2793591 seconds > Total time for which application threads were stopped: 0.0051265 seconds > Application time: 290.7301471 seconds > Total time for which application threads were stopped: 0.0070431 seconds > Application time: 9.2694376 seconds > Total time for which application threads were stopped: 0.0051428 seconds > Application time: 119.4074368 seconds > Total time for which application threads were stopped: 0.0059739 seconds > Application time: 39.8647697 seconds > 2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew > Desired survivor size 14450688 bytes, new threshold 1 (max 1) > - age 1: 2911824 bytes, 2911824 total > > -Xms3072m > -Xmx3072m > -Xmn2944m > -XX:+DisableExplicitGC > -XX:+PrintGCDetails > -XX:+PrintGCDateStamps > -XX:+PrintGCApplicationStoppedTime > -XX:+PrintGCApplicationConcurrentTime > -XX:MaxTenuringThreshold=1 > -XX:SurvivorRatio=190 > -XX:TargetSurvivorRatio=90 > -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100420/7dfc2ada/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From opinali at gmail.com Tue Apr 20 13:10:01 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Tue, 20 Apr 2010 17:10:01 -0300 Subject: What influences young generation pause times? In-Reply-To: <4BCDEE6F.8030807@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> Message-ID: Hi Tony, Osvaldo, > > You misunderstand how a copying GC (which is the algorithm our young gen > GCs implement) works. It does not first mark the live objects, and then > copies them. Instead, it copies the objects as it comes across them (i.e., > at the same time it discovers they are live). So, there is no opportunity to > find big blocks of live objects and not copy them. The end of the GC would > be the only time you would be able to do that but, by then, you've already > copied all the objects anyway. > That's right, but (as my thinking went) just one possible implementation - but I failed to notice that an ideal solution would require combining both algorithms in some way that is not possible without a hit for the non-lucky case of needing to copy. > Regarding calling young GCs explicitly from an application: I can see how, > in the case of single-threaded applications, the application might know "We > are between transactions and, maybe, we have lots of garbage and not much > live in the young gen. So let's do a young GC to clean up the young gen at > maybe low overhead since we'll copy very little." However, how will this > work in the case of multi-threaded applications, which are the vast majority > of applications we see from our customers? A thread might be between > transactions, but what about the other 50, 300, or even 2,000 threads? If a > particular time is good to do a young GC Not all multithreaded apps are heavily multithreaded; for each mammoth website with 2000 concurrent transactions, you'll find a thousand corporate apps with peaks of 5 concurrent transactions and very frequent full-idle periods. Well, admittedly for these apps, cutting the cost of young-GCs copying is irrelevant; it's the former, larger apps that need it. I guess at least my speculation about (big) TLAB collection is valid? And what about the large number of non-EE apps - remarkably media-heavy / RIA / games, which are typically "almost-single-threaded" = event dispatch thread plus two or three application threads, typically tightly controlled (so it's trivial and cheap to force all these threads to stop in a barrier when you want to clean up). These apps are often very sensitive to latency: a stop-the-world 50ms pause at the wrong time are sufficient to result in visible or audible stuttering. [Java GC should not care only for the Enterprise side. If you peek into some dev communities - e.g. javagaming.org - people are always whining about insufficient control over GC behavior. What we want is something like RTSJ's scoped heaps - you "enter" some execution phase, allocate lots of Young objects, then you "leave" this phase and request GC that will be basically free - but of course, we need something that works in the JavaSE and JavaME platforms, without the complexities and mutator costs of RTSJ.] > for a particular thread, it does not mean that it's also good for the rest. > Additionally, I would be willing to bet money that if we provided such an > API, library writers will abuse it thinking that "hey, the end of this > library call will be a great time to do a young GC!", without taking into > consideration that many other threads could be doing something totally > different at the same time (we've seen way too many libraries that call > System.gc() already...). > This is true, but I guess the problem could be handled by the Security manager and/or VM options, maybe allowing only certain packages to induce GC in any way. There is precedent for that (-XX:+DisableExplicitGC, and default configuration of app servers to use that option). The problem exisits but it's not new in any "lightweight GC API" proposal - even to current date I sometimes find some app code that invokes Good Old System.gc(). Please let's not use the "developers will shoot themselves in the foot" argument, to not provide a solution for a very painful problem. :) A+ Osvaldo > > My two cents, > > Tony > > Osvaldo Doederlein wrote: > >> If you allow some intermission... is the young-gen collector smart enough >> to avoid semispace copying in some favorable conditions? Let's say I am >> lucky and when young-GC is triggered, after marking I have [LLLLLLLLLLDDDD] >> where L=live objects, D=dead. it's stupid to copy the block [LLLLLLLLLL] to >> another space. I'd expect the collector to have some heuristic like: look at >> the top address and total size of the remaining live data, and if it is >> densely populated (say >90% live space - e.g. [LLLDLLLLLLDDDD]), just finish >> GC without any compaction or semispace flipping. >> >> I would expect this scenario to happen in the real world with very small >> frequency, because young-GC must be triggered at a "lucky" time, e.g. after >> some application transactions commit and before any newer transaction begins >> - but if the collector already accounts the live set size at the marking >> phase, the cost to attempt this new optimization is virtually zero. And we >> might hint the VM to make sure the optimal case doesn't depend on good luck. >> The JVM could expose an API that allows an application (or a container) to >> request a "lightweight GC", i.e., perform only young-GC, and only if the >> young-gen is >N% full. E.g., System.fastGC(0.8) for N=80%. A JavaEE >> application server could invoke this when it detects idle periods (zero >> running transactions / zero background processes doing anything important); >> or even after every transaction commit if the VM uses TLABs (in that case we >> only collect the TLAB; the whole thing only makes sense for large enough >> TLABs). For single-threaded processes (Ok, almost-single-threaded...) it's >> much simpler, just call the lightweight-GC API at special places where major >> activity ends and tons of allocated data are liberated, e.g. after the >> render-frame step of your game loop, or after importing each file in your >> batch ETL program, etc. >> >> A+ >> Osvaldo >> >> 2010/4/20 Matt Khan > >> >> >> Hi Tony >> >> >> Basically, the more objects survive the collection and need to be >> copied, the higher the young GC times will be. >> so when does a concurrent collector enter a STW pause? >> >> for example if I look at figure 6, p10 in the memory management white >> paper (http://java.sun.com/products/hotspot/whitepaper.html) then that >> makes it look like there is a single STW pause per young >> collection that >> is made shorter because there are n threads doing the work. Is that an >> accurate depiction of when it pauses or just a convenient >> visualisation? >> >> My reason for asking is that my app doesn't exhibit this single >> pause per >> young collection, instead I see a succession of short pauses >> between GC >> logs (example below) & I'd like to understand what causes those >> pauses. >> This app is using CMS (params used below) but there is no CMS activity >> reported at this time because v little enters the tenured >> generation and >> hence there is no collection required. >> >> Total time for which application threads were stopped: 0.0051359 >> seconds >> Application time: 99.9576332 seconds >> 2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew >> Desired survivor size 14450688 bytes, new threshold 1 (max 1) >> - age 1: 3377144 bytes, 3377144 total >> : 2986668K->4491K(2998976K), 0.0254753 secs] >> 3076724K->94963K(3130048K) >> icms_dc=0 , 0.0259072 secs] [Time >> s: user=0.25 sys=0.01, real=0.03 secs] >> Total time for which application threads were stopped: 0.0330759 >> seconds >> Application time: 190.7387185 seconds >> Total time for which application threads were stopped: 0.0060798 >> seconds >> Application time: 9.2698867 seconds >> Total time for which application threads were stopped: 0.0051861 >> seconds >> Application time: 290.7195886 seconds >> Total time for which application threads were stopped: 0.0065455 >> seconds >> Application time: 9.2792321 seconds >> Total time for which application threads were stopped: 0.0051541 >> seconds >> Application time: 290.7292153 seconds >> Total time for which application threads were stopped: 0.0063071 >> seconds >> Application time: 9.2696694 seconds >> Total time for which application threads were stopped: 0.0052036 >> seconds >> Application time: 290.7093779 seconds >> Total time for which application threads were stopped: 0.0065365 >> seconds >> Application time: 9.2793591 seconds >> Total time for which application threads were stopped: 0.0051265 >> seconds >> Application time: 290.7301471 seconds >> Total time for which application threads were stopped: 0.0070431 >> seconds >> Application time: 9.2694376 seconds >> Total time for which application threads were stopped: 0.0051428 >> seconds >> Application time: 119.4074368 seconds >> Total time for which application threads were stopped: 0.0059739 >> seconds >> Application time: 39.8647697 seconds >> 2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew >> Desired survivor size 14450688 bytes, new threshold 1 (max 1) >> - age 1: 2911824 bytes, 2911824 total >> >> -Xms3072m >> -Xmx3072m >> -Xmn2944m >> -XX:+DisableExplicitGC >> -XX:+PrintGCDetails >> -XX:+PrintGCDateStamps >> -XX:+PrintGCApplicationStoppedTime >> -XX:+PrintGCApplicationConcurrentTime >> -XX:MaxTenuringThreshold=1 >> -XX:SurvivorRatio=190 >> -XX:TargetSurvivorRatio=90 >> -XX:+UseConcMarkSweepGC >> -XX:+UseParNewGC >> >> Cheers >> Matt >> >> Matt Khan >> -------------------------------------------------- >> GFFX Auto Trading >> Deutsche Bank, London >> >> >> >> --- >> >> This e-mail may contain confidential and/or privileged >> information. If you are not the intended recipient (or have >> received this e-mail in error) please notify the sender >> immediately and delete this e-mail. Any unauthorized copying, >> disclosure or distribution of the material in this e-mail is >> strictly forbidden. >> >> Please refer to http://www.db.com/en/content/eu_disclosures.htm >> for additional EU corporate and regulatory disclosures. >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> >> >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100420/f4599e2a/attachment-0001.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From matt.khan at db.com Tue Apr 20 13:30:32 2010 From: matt.khan at db.com (Matt Khan) Date: Tue, 20 Apr 2010 21:30:32 +0100 Subject: What influences young generation pause times? In-Reply-To: <4BCDF1EB.2010605@oracle.com> Message-ID: >> You might need a VM with this fix. 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate OK so that's the early access for 6u21 by the looks of it. I'll repeat a run on that JVM (and with the safepoint stats). >> If the log doesn't show a [GC...] line at a safepoint, then there is not GC activity during it does this mean that the actual time stopped due to GC is the one immediately after the GC line? >> You could use -XX:+PrintSafepointStatistics etc. to figure these out. which other flags should I look at? Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100420/51fd8c39/attachment.html -------------- next part -------------- _______________________________________________ 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 oracle.com Tue Apr 20 13:39:34 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 20 Apr 2010 13:39:34 -0700 Subject: What influences young generation pause times? In-Reply-To: References: Message-ID: <4BCE1106.1060400@oracle.com> On 04/20/10 13:30, Matt Khan wrote: > > >> You might need a VM with this fix. 6782663: Data produced by > PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is > not accurate > OK so that's the early access for 6u21 by the looks of it. I'll repeat > a run on that JVM (and with the safepoint stats). > > >> If the log doesn't show a [GC...] line at a safepoint, then there > is not GC activity during it > does this mean that the actual time stopped due to GC is the one > immediately after the GC line? As you can see more than GC can contribute to a STW so the "time stopped" might include other times that don't log any message. The GC entries in the log print their own times. > > > >> You could use -XX:+PrintSafepointStatistics etc. to figure these out. > which other flags should I look at? I don't know of any others. > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > --- > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. > Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100420/e06abd93/attachment.html -------------- next part -------------- _______________________________________________ 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 oracle.com Tue Apr 20 13:56:57 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 20 Apr 2010 13:56:57 -0700 Subject: What influences young generation pause times? In-Reply-To: References: Message-ID: <4BCE1519.808@oracle.com> On 04/20/10 13:30, Matt Khan wrote: ... > >> You could use -XX:+PrintSafepointStatistics etc. to figure these out. > which other flags should I look at? product(bool, PrintSafepointStatistics, false, \ "print statistics about safepoint synchronization") \ \ product(intx, PrintSafepointStatisticsCount, 300, \ "total number of safepoint statistics collected " \ "before printing them out") \ The o/p might go to stdout, rather than to the gc log file in case you have the one redirected and not the other. Once you know what those safepoints are for, you can use more specific flags to see what's happening there (for example as Tony conjectured perhaps biased locking; or global deoptimization due to class loading etc.) -- ramki _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From matt.khan at db.com Tue Apr 20 14:14:35 2010 From: matt.khan at db.com (Matt Khan) Date: Tue, 20 Apr 2010 22:14:35 +0100 Subject: What influences young generation pause times? In-Reply-To: <4BCE1519.808@oracle.com> Message-ID: perhaps this should be on the runtime list but since it's relevant to this thread I'll ask here.... I'm periodically getting output like RevokeBias [ 238 0 1] [ 0 0 0] [ 0 7] 0 headed by one of these Total time for wh [ 0 0 0] [ 0 14] 0 the lines are overwhelmingly RevokeBias or BulkRevokeBias Can you explain what these values are? I'm not especially familiar with the hotspot source code so am unsure where I'd find this info in the src alone. Cheers Matt Matt Khan -------------------------------------------------- GFFX Auto Trading Deutsche Bank, London --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100420/c951917a/attachment.html -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From rocketraman at fastmail.fm Tue Apr 20 14:53:14 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Tue, 20 Apr 2010 17:53:14 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BCDEE6F.8030807@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> Message-ID: <4BCE224A.1000306@fastmail.fm> On 04/20/2010 02:11 PM, Tony Printezis wrote: > Additionally, I would be willing to bet money that if we provided such > an API, library writers will abuse it thinking that "hey, the end of > this library call will be a great time to do a young GC!", without > taking into consideration that many other threads could be doing > something totally different at the same time (we've seen way too many > libraries that call System.gc() already...). While I wasn't talking about young GC's, a couple of years ago I submitted a proposal to to this list to add a new RuntimePermission that would allow execution of explicit GCs [1]. Without such permission, the System.gc() call would simply return without doing anything. Ideally the signature would be modified to return a boolean "true if performed", "false if not", and even more ideally, a more comprehensive GC API could be provided. Such an approach would allow the addition of some explicit GC control from applications, without allowing abuse by random libraries. While a couple of people chimed in that they too would like some explicit GC control, the proposal was ignored. [1] http://markmail.org/message/cpmpwoodbcmspesc I'd at least like to hear some reasons why something like this can't be done or isn't a good idea. I think it would be a great feature for many people. Cheers, Raman From y.s.ramakrishna at oracle.com Tue Apr 20 15:37:08 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Tue, 20 Apr 2010 15:37:08 -0700 Subject: What influences young generation pause times? In-Reply-To: References: Message-ID: <4BCE2C94.8090006@oracle.com> On 04/20/10 14:14, Matt Khan wrote: > > perhaps this should be on the runtime list but since it's relevant to > this thread I'll ask here.... > > I'm periodically getting output like > > RevokeBias [ 238 0 1] > [ 0 0 0] [ 0 7] 0 > > headed by one of these > > Total time for wh [ 0 0 0] [ 0 14] 0 > > the lines are overwhelmingly RevokeBias or BulkRevokeBias > > Can you explain what these values are? I'm not especially familiar with > the hotspot source code so am unsure where I'd find this info in the src > alone. If you are asking about the columns in each record, check the header line which should have been printed earlier. If you use a more recent JVM (hs18) you should see the column headings printed more frequently than the sole initial appearance in the log produced by older jvm's. For background on biased locking and associated flags, and what is involved in bias revocation etc, read http://portal.acm.org/citation.cfm?doid=1167473.1167496 Experiment with -XX:-UseBiasedLocking if it's not working well for you, or if it is interfering with your predictability objectives (read the article for when biased locking may not work well and how it may affect predictability), and contact your Java support for further tuning help, questions, to report a performance bug, etc. all the best. -- ramki > > Cheers > Matt > > Matt Khan > -------------------------------------------------- > GFFX Auto Trading > Deutsche Bank, London > > > --- > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Wed Apr 21 08:01:49 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Apr 2010 11:01:49 -0400 Subject: What influences young generation pause times? In-Reply-To: References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> Message-ID: <4BCF135D.8030808@oracle.com> Osvaldo, Osvaldo Doederlein wrote: > > Regarding calling young GCs explicitly from an application: I can > see how, in the case of single-threaded applications, the > application might know "We are between transactions and, maybe, we > have lots of garbage and not much live in the young gen. So let's > do a young GC to clean up the young gen at maybe low overhead > since we'll copy very little." However, how will this work in the > case of multi-threaded applications, which are the vast majority > of applications we see from our customers? A thread might be > between transactions, but what about the other 50, 300, or even > 2,000 threads? If a particular time is good to do a young GC > > > Not all multithreaded apps are heavily multithreaded; for each mammoth > website with 2000 concurrent transactions, you'll find a thousand > corporate apps with peaks of 5 concurrent transactions and very > frequent full-idle periods. Well, admittedly for these apps, cutting > the cost of young-GCs copying is irrelevant; :-) > it's the former, larger apps that need it. I guess at least my > speculation about (big) TLAB collection is valid? I'm not quite sure what you mean by big TLAB collection. You mean to collect just the TLABs of a thread. You really cannot do that without scanning the entire young gen to find all the references into them. > And what about the large number of non-EE apps - remarkably > media-heavy / RIA / games, which are typically > "almost-single-threaded" = event dispatch thread plus two or three > application threads, typically tightly controlled (so it's trivial and > cheap to force all these threads to stop in a barrier when you want to > clean up). I haven't talked to many customers who will be willing to introduce their own safepoints in their Java code. > These apps are often very sensitive to latency: a stop-the-world 50ms > pause at the wrong time are sufficient to result in visible or audible > stuttering. > > [Java GC should not care only for the Enterprise side. If you peek > into some dev communities - e.g. javagaming.org > - people are always whining about insufficient > control over GC behavior. What we want is something like RTSJ's scoped > heaps - you "enter" some execution phase, allocate lots of Young > objects, then you "leave" this phase and request GC that will be > basically free - but of course, we need something that works in the > JavaSE and JavaME platforms, without the complexities and mutator > costs of RTSJ.] Let's assume you want to use something like RTSJ's scopes (and let's say they are simplified and assume only one thread will enter them, which removes a lot of the complexity associated with RTSJ's scopes). Then the only way to be able to reclaim a scope when you leave it is to ensure that there are no references from outside the scope into it. You can ensure that this is the case by introducing write barriers and throwing an exception if such a reference is created (which is what the RTSJ does), but now a lot of the existing code won't work correctly with this restriction. So, you just cannot do what you're proposing without some extra costs. We have been working on, and thinking about GC, for a long time. Trust me, if there was a way to do cheaply what you're proposing, we would have done it a long time ago. With the semantics of Java it's not straightforward. And, after many years of doing this stuff, I can also assure you that nothing in GC it's "free". ;-) > > > for a particular thread, it does not mean that it's also good for > the rest. Additionally, I would be willing to bet money that if we > provided such an API, library writers will abuse it thinking that > "hey, the end of this library call will be a great time to do a > young GC!", without taking into consideration that many other > threads could be doing something totally different at the same > time (we've seen way too many libraries that call System.gc() > already...). > > > This is true, but I guess the problem could be handled by the Security > manager and/or VM options, maybe allowing only certain packages to > induce GC in any way. There is precedent for that > (-XX:+DisableExplicitGC, and default configuration of app servers to > use that option). The problem exisits but it's not new in any > "lightweight GC API" proposal - even to current date I sometimes find > some app code that invokes Good Old System.gc(). Please let's not use > the "developers will shoot themselves in the foot" argument, to not > provide a solution for a very painful problem. :) On the contrary, our mission is to prevent developers from shooting themselves in the foot. :-) Tony _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From opinali at gmail.com Wed Apr 21 11:55:30 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Wed, 21 Apr 2010 15:55:30 -0300 Subject: What influences young generation pause times? In-Reply-To: <4BCF135D.8030808@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCF135D.8030808@oracle.com> Message-ID: Tony, 2010/4/21 Tony Printezis > I'm not quite sure what you mean by big TLAB collection. You mean to > collect just the TLABs of a thread. You really cannot do that without > scanning the entire young gen to find all the references into them. I didn't know that, I was supposing that the TLAB would have a remset for incoming references from the rest of the young gen. > Let's assume you want to use something like RTSJ's scopes (and let's say > they are simplified and assume only one thread will enter them, which > removes a lot of the complexity associated with RTSJ's scopes). Then the > only way to be able to reclaim a scope when you leave it is to ensure that > there are no references from outside the scope into it. You can ensure that > this is the case by introducing write barriers and throwing an exception if > such a reference is created (which is what the RTSJ does), but now a lot of > the existing code won't work correctly with this restriction. So, you just > cannot do what you're proposing without some extra costs. > To make my suggestion more clear, the intention is just enabling something similar to RTSJ. While "inside" some scope, the program can introduce references from old to new objects, as long as these refs are all cleared when "exiting" the scope. By "request GC that will be basically free" I didn't mean something identical to RTSJ (free() a whole heap block), but only trigger the young-GC -- at that time, all those young objects are unreachable. Except perhaps a few objects that existed before entering the scope - not a problem, they are all compacted in the beginning of the YG, so young-GC will be only slightly slower than for zero live objects, no big deal. (I'm also not wishing for real-time GC guarantees like in RTSJ.) > We have been working on, and thinking about GC, for a long time. Trust me, > if there was a way to do cheaply what you're proposing, we would have done > it a long time ago. With the semantics of Java it's not straightforward. > And, after many years of doing this stuff, I can also assure you that > nothing in GC it's "free". ;-) I certainly believe this - I'm not suggesting anything that would be really free. In all suggestions I would expect some hit in overall throughput (thread-local young gens would have this cost because we potentially increase the working set, so reduced cache efficiency alone should more than offset the cycles saved in GC). In other cases - fine-grained explicit GC API + strict threading/allocation behavior required for near-instant young GC - the cost is programming complexity. These costs would be fine for a great many apps. Let's put it differently: why not adding a simple API like I suggested (trigger only young-GC, perhaps with a parameter to only do that if the young gen has less than some % of free space)? I'd expect this to be trivial to implement. Maybe we could have this in some sun.* package, and only in non-release builds for extra protection. Let people kick the tires and give you feedback - whether this produces significant benefits for some apps. A+ Osvaldo > > >> for a particular thread, it does not mean that it's also good for >> the rest. Additionally, I would be willing to bet money that if we >> provided such an API, library writers will abuse it thinking that >> "hey, the end of this library call will be a great time to do a >> young GC!", without taking into consideration that many other >> threads could be doing something totally different at the same >> time (we've seen way too many libraries that call System.gc() >> already...). >> >> >> This is true, but I guess the problem could be handled by the Security >> manager and/or VM options, maybe allowing only certain packages to induce GC >> in any way. There is precedent for that (-XX:+DisableExplicitGC, and default >> configuration of app servers to use that option). The problem exisits but >> it's not new in any "lightweight GC API" proposal - even to current date I >> sometimes find some app code that invokes Good Old System.gc(). Please let's >> not use the "developers will shoot themselves in the foot" argument, to not >> provide a solution for a very painful problem. :) >> > On the contrary, our mission is to prevent developers from shooting > themselves in the foot. :-) > > Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100421/9432d250/attachment.html -------------- next part -------------- _______________________________________________ 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 oracle.com Wed Apr 21 15:12:22 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 21 Apr 2010 15:12:22 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BCE224A.1000306@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> Message-ID: <4BCF7846.5080701@oracle.com> Raman, There is no shortage of good ideas for the GC team to work on. RuntimePermission might be another one, but the simple fact is that we don't have time to work on everything we should. Right now our top priorities are reliability, faster GC's and more predictable GC's. Anything else is a hard sell. Jon On 04/20/10 14:53, Raman Gupta wrote: > On 04/20/2010 02:11 PM, Tony Printezis wrote: >> Additionally, I would be willing to bet money that if we provided such >> an API, library writers will abuse it thinking that "hey, the end of >> this library call will be a great time to do a young GC!", without >> taking into consideration that many other threads could be doing >> something totally different at the same time (we've seen way too many >> libraries that call System.gc() already...). > > While I wasn't talking about young GC's, a couple of years ago I > submitted a proposal to to this list to add a new RuntimePermission > that would allow execution of explicit GCs [1]. Without such > permission, the System.gc() call would simply return without doing > anything. Ideally the signature would be modified to return a boolean > "true if performed", "false if not", and even more ideally, a more > comprehensive GC API could be provided. > > Such an approach would allow the addition of some explicit GC control > from applications, without allowing abuse by random libraries. > > While a couple of people chimed in that they too would like some > explicit GC control, the proposal was ignored. > > [1] http://markmail.org/message/cpmpwoodbcmspesc > > I'd at least like to hear some reasons why something like this can't > be done or isn't a good idea. I think it would be a great feature for > many people. > > Cheers, > Raman From rocketraman at fastmail.fm Wed Apr 21 15:36:02 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Wed, 21 Apr 2010 18:36:02 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BCF7846.5080701@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> Message-ID: <4BCF7DD2.5000104@fastmail.fm> On 04/21/2010 06:12 PM, Jon Masamitsu wrote: > There is no shortage of good ideas for the GC team to work on. > RuntimePermission might be another one, but the simple fact is > that we don't have time to work on everything we should. Right > now our top priorities are reliability, faster GC's and more > predictable GC's. Anything else is a hard sell. Thanks Jon. I've never contributed to the JDK before, but I suspect that implementing the first phase of this particular feature as I described it would be very easy (basically just gate System.gc() with a new RuntimePermission). But before I go spend hours trying to figure out how to download and build the JDK, and contribute a patch, it would be nice to know if it has a good chance of being accepted. Note that this goes directly towards the goal of predictable GCs. For example, one of my current server applications generally does one or two full GCs daily. Currently, that full GC takes about 3-4 seconds, but its timing is based solely on the size of the old gen, and is completely unpredictable -- it could occur in the middle of the night (good) or it could occur during peak time (bad). My solution would allow my app to schedule the full GC overnight (subject to the non-guaranteed constraints of System.gc, of course, but in practice System.gc seems to pretty reliably kick off a full GC), with which the app will almost certainly make it through the peak period without another full GC occurring. I do of course understand there would be significant work involved by the GC team just to review and accept such a patch, so I completely understand if the answer is no. Cheers, Raman From jon.masamitsu at oracle.com Wed Apr 21 15:56:42 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 21 Apr 2010 15:56:42 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BCF7DD2.5000104@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> Message-ID: <4BCF82AA.4040804@oracle.com> Raman, Define this GC API for me. Where is the API (Java class)? Jon > Without such permission, the System.gc() call would simply return without doing anything. Ideally the signature would be > modified to return a boolean "true if performed", "false if not", and even more ideally, a more comprehensive GC API could be > provided. On 04/21/10 15:36, Raman Gupta wrote: > On 04/21/2010 06:12 PM, Jon Masamitsu wrote: >> There is no shortage of good ideas for the GC team to work on. >> RuntimePermission might be another one, but the simple fact is >> that we don't have time to work on everything we should. Right >> now our top priorities are reliability, faster GC's and more >> predictable GC's. Anything else is a hard sell. > > Thanks Jon. > > I've never contributed to the JDK before, but I suspect that > implementing the first phase of this particular feature as I described > it would be very easy (basically just gate System.gc() with a new > RuntimePermission). But before I go spend hours trying to figure out > how to download and build the JDK, and contribute a patch, it would be > nice to know if it has a good chance of being accepted. > > Note that this goes directly towards the goal of predictable GCs. For > example, one of my current server applications generally does one or > two full GCs daily. Currently, that full GC takes about 3-4 seconds, > but its timing is based solely on the size of the old gen, and is > completely unpredictable -- it could occur in the middle of the night > (good) or it could occur during peak time (bad). My solution would > allow my app to schedule the full GC overnight (subject to the > non-guaranteed constraints of System.gc, of course, but in practice > System.gc seems to pretty reliably kick off a full GC), with which the > app will almost certainly make it through the peak period without > another full GC occurring. > > I do of course understand there would be significant work involved by > the GC team just to review and accept such a patch, so I completely > understand if the answer is no. > > Cheers, > Raman From rocketraman at fastmail.fm Wed Apr 21 16:19:54 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Wed, 21 Apr 2010 19:19:54 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BCF82AA.4040804@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> Message-ID: <4BCF881A.9050309@fastmail.fm> I am not suggesting any new API at this time -- I mentioned it only as a pie-in-the-sky kind of thing. My current suggestion is simply to gate System.gc() (or actually Runtime.gc() I guess) with a new RuntimePermission. Without the appropriate permission granted, gc() would simply be a no-op. That on its own would be very useful by allowing application code to call System.gc() without worrying about rogue libraries also doing so at inopportune times. Currently, I always run with -XX:+DisableExplicitGC but that also prevents my app from scheduling it. Cheers, Raman On 04/21/2010 06:56 PM, Jon Masamitsu wrote: > Raman, > > Define this GC API for me. Where is the API (Java class)? > > Jon > > > Without such permission, the System.gc() call would simply return > without doing anything. Ideally the signature would be > > modified to return a boolean "true if performed", "false if not", and > even more ideally, a more comprehensive GC API could be > > provided. > > On 04/21/10 15:36, Raman Gupta wrote: >> On 04/21/2010 06:12 PM, Jon Masamitsu wrote: >>> There is no shortage of good ideas for the GC team to work on. >>> RuntimePermission might be another one, but the simple fact is >>> that we don't have time to work on everything we should. Right >>> now our top priorities are reliability, faster GC's and more >>> predictable GC's. Anything else is a hard sell. >> >> Thanks Jon. >> >> I've never contributed to the JDK before, but I suspect that >> implementing the first phase of this particular feature as I described >> it would be very easy (basically just gate System.gc() with a new >> RuntimePermission). But before I go spend hours trying to figure out >> how to download and build the JDK, and contribute a patch, it would be >> nice to know if it has a good chance of being accepted. >> >> Note that this goes directly towards the goal of predictable GCs. For >> example, one of my current server applications generally does one or >> two full GCs daily. Currently, that full GC takes about 3-4 seconds, >> but its timing is based solely on the size of the old gen, and is >> completely unpredictable -- it could occur in the middle of the night >> (good) or it could occur during peak time (bad). My solution would >> allow my app to schedule the full GC overnight (subject to the >> non-guaranteed constraints of System.gc, of course, but in practice >> System.gc seems to pretty reliably kick off a full GC), with which the >> app will almost certainly make it through the peak period without >> another full GC occurring. >> >> I do of course understand there would be significant work involved by >> the GC team just to review and accept such a patch, so I completely >> understand if the answer is no. >> >> Cheers, >> Raman From tony.printezis at oracle.com Wed Apr 21 16:27:02 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Apr 2010 19:27:02 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BCF881A.9050309@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> Message-ID: <4BCF89C6.9090802@oracle.com> Raman Gupta wrote: > I am not suggesting any new API at this time -- I mentioned it only as > a pie-in-the-sky kind of thing. > > My current suggestion is simply to gate System.gc() (or actually > Runtime.gc() I guess) with a new RuntimePermission. Without the > appropriate permission granted, gc() would simply be a no-op. > > That on its own would be very useful by allowing application code to > call System.gc() without worrying about rogue libraries also doing so > at inopportune times. Currently, I always run with > -XX:+DisableExplicitGC but that also prevents my app from scheduling it. Raman, if you want to cause a Full GC on your app while you have +DisableExplicitGC, one of the things you can do is to call jmap -histo:live on the JVM. The Full GCs initiated by the heap inspection tools ignore +DisableExplicitGC. Not pretty, but it should work... FWIW. Tony > Cheers, > Raman > > > On 04/21/2010 06:56 PM, Jon Masamitsu wrote: >> Raman, >> >> Define this GC API for me. Where is the API (Java class)? >> >> Jon >> >> > Without such permission, the System.gc() call would simply return >> without doing anything. Ideally the signature would be >> > modified to return a boolean "true if performed", "false if not", and >> even more ideally, a more comprehensive GC API could be >> > provided. >> >> On 04/21/10 15:36, Raman Gupta wrote: >>> On 04/21/2010 06:12 PM, Jon Masamitsu wrote: >>>> There is no shortage of good ideas for the GC team to work on. >>>> RuntimePermission might be another one, but the simple fact is >>>> that we don't have time to work on everything we should. Right >>>> now our top priorities are reliability, faster GC's and more >>>> predictable GC's. Anything else is a hard sell. >>> >>> Thanks Jon. >>> >>> I've never contributed to the JDK before, but I suspect that >>> implementing the first phase of this particular feature as I described >>> it would be very easy (basically just gate System.gc() with a new >>> RuntimePermission). But before I go spend hours trying to figure out >>> how to download and build the JDK, and contribute a patch, it would be >>> nice to know if it has a good chance of being accepted. >>> >>> Note that this goes directly towards the goal of predictable GCs. For >>> example, one of my current server applications generally does one or >>> two full GCs daily. Currently, that full GC takes about 3-4 seconds, >>> but its timing is based solely on the size of the old gen, and is >>> completely unpredictable -- it could occur in the middle of the night >>> (good) or it could occur during peak time (bad). My solution would >>> allow my app to schedule the full GC overnight (subject to the >>> non-guaranteed constraints of System.gc, of course, but in practice >>> System.gc seems to pretty reliably kick off a full GC), with which the >>> app will almost certainly make it through the peak period without >>> another full GC occurring. >>> >>> I do of course understand there would be significant work involved by >>> the GC team just to review and accept such a patch, so I completely >>> understand if the answer is no. >>> >>> Cheers, >>> Raman From jon.masamitsu at oracle.com Wed Apr 21 23:22:38 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 21 Apr 2010 23:22:38 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BCF881A.9050309@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> Message-ID: <4BCFEB2E.20108@oracle.com> On 4/21/10 4:19 PM, Raman Gupta wrote: > I am not suggesting any new API at this time -- I mentioned it only as > a pie-in-the-sky kind of thing. > > My current suggestion is simply to gate System.gc() (or actually > Runtime.gc() I guess) with a new RuntimePermission. Without the > appropriate permission granted, gc() would simply be a no-op. I know very little about RuntimePermission. Who needs to be involved in creating a new one? > > That on its own would be very useful by allowing application code to > call System.gc() without worrying about rogue libraries also doing so > at inopportune times. Currently, I always run with > -XX:+DisableExplicitGC but that also prevents my app from scheduling it. > > Cheers, > Raman > > > On 04/21/2010 06:56 PM, Jon Masamitsu wrote: >> Raman, >> >> Define this GC API for me. Where is the API (Java class)? >> >> Jon >> >> > Without such permission, the System.gc() call would simply return >> without doing anything. Ideally the signature would be >> > modified to return a boolean "true if performed", "false if not", and >> even more ideally, a more comprehensive GC API could be >> > provided. >> >> On 04/21/10 15:36, Raman Gupta wrote: >>> On 04/21/2010 06:12 PM, Jon Masamitsu wrote: >>>> There is no shortage of good ideas for the GC team to work on. >>>> RuntimePermission might be another one, but the simple fact is >>>> that we don't have time to work on everything we should. Right >>>> now our top priorities are reliability, faster GC's and more >>>> predictable GC's. Anything else is a hard sell. >>> >>> Thanks Jon. >>> >>> I've never contributed to the JDK before, but I suspect that >>> implementing the first phase of this particular feature as I described >>> it would be very easy (basically just gate System.gc() with a new >>> RuntimePermission). But before I go spend hours trying to figure out >>> how to download and build the JDK, and contribute a patch, it would be >>> nice to know if it has a good chance of being accepted. >>> >>> Note that this goes directly towards the goal of predictable GCs. For >>> example, one of my current server applications generally does one or >>> two full GCs daily. Currently, that full GC takes about 3-4 seconds, >>> but its timing is based solely on the size of the old gen, and is >>> completely unpredictable -- it could occur in the middle of the night >>> (good) or it could occur during peak time (bad). My solution would >>> allow my app to schedule the full GC overnight (subject to the >>> non-guaranteed constraints of System.gc, of course, but in practice >>> System.gc seems to pretty reliably kick off a full GC), with which the >>> app will almost certainly make it through the peak period without >>> another full GC occurring. >>> >>> I do of course understand there would be significant work involved by >>> the GC team just to review and accept such a patch, so I completely >>> understand if the answer is no. >>> >>> Cheers, >>> Raman From rocketraman at fastmail.fm Thu Apr 22 09:13:15 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Thu, 22 Apr 2010 12:13:15 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BCF89C6.9090802@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCF89C6.9090802@oracle.com> Message-ID: <4BD0759B.7090804@fastmail.fm> On 04/21/2010 07:27 PM, Tony Printezis wrote: > Raman Gupta wrote: >> I am not suggesting any new API at this time -- I mentioned it only as >> a pie-in-the-sky kind of thing. >> >> My current suggestion is simply to gate System.gc() (or actually >> Runtime.gc() I guess) with a new RuntimePermission. Without the >> appropriate permission granted, gc() would simply be a no-op. >> >> That on its own would be very useful by allowing application code to >> call System.gc() without worrying about rogue libraries also doing so >> at inopportune times. Currently, I always run with >> -XX:+DisableExplicitGC but that also prevents my app from scheduling it. >> > Raman, if you want to cause a Full GC on your app while you have > +DisableExplicitGC, one of the things you can do is to call jmap > -histo:live on the JVM. The Full GCs initiated by the heap > inspection tools ignore +DisableExplicitGC. Not pretty, but it should > work... FWIW. Nice hack :) From rocketraman at fastmail.fm Thu Apr 22 09:24:52 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Thu, 22 Apr 2010 12:24:52 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BCFEB2E.20108@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> Message-ID: <4BD07854.1020903@fastmail.fm> On 04/22/2010 02:22 AM, Jon Masamitsu wrote: > On 4/21/10 4:19 PM, Raman Gupta wrote: >> I am not suggesting any new API at this time -- I mentioned it only as >> a pie-in-the-sky kind of thing. >> >> My current suggestion is simply to gate System.gc() (or actually >> Runtime.gc() I guess) with a new RuntimePermission. Without the >> appropriate permission granted, gc() would simply be a no-op. > > I know very little about RuntimePermission. Who needs to be involved in > creating > a new one? It seems the core libraries group is responsible for anything in java.lang, which both SecurityManager and RuntimePermission are: http://openjdk.java.net/groups/core-libs/ So presumably both the GC group and the core libraries group would have to be ok with this change. If you guys are ok with this in principle, I can coordinate getting approval from the core-libs group via their mailing list. I would also need a sponsor -- I don't know if they would be from gc-dev or core-libs or both. Documentation like this one would have to be updated as well -- if this is part of the JDK source then that is easy enough: http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html Cheers, Raman From y.s.ramakrishna at oracle.com Thu Apr 22 12:35:09 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Thu, 22 Apr 2010 12:35:09 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BD07854.1020903@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> Message-ID: <4BD0A4ED.9070907@oracle.com> Raman, FWIW, it appears to me that all of the action here is really at the core libraries level (including System.gc()), except at the point at which it interacts with the current semantics of the vm option DisableExplicitGC (which should really become a default global property spec rather than a JVM flag at that point). So, to me at least, it appears reasonable that this proposal start with the appropriate core-libraries sponsor. Interactions with existing vm options, jconsole, jmap and mbean controls etc. will need to be worked out in concert with the core libs (sponsors), the serviceability team and the gc team as the spec for this is crystallized. my $0.02. -- ramki On 04/22/10 09:24, Raman Gupta wrote: > On 04/22/2010 02:22 AM, Jon Masamitsu wrote: >> On 4/21/10 4:19 PM, Raman Gupta wrote: >>> I am not suggesting any new API at this time -- I mentioned it only as >>> a pie-in-the-sky kind of thing. >>> >>> My current suggestion is simply to gate System.gc() (or actually >>> Runtime.gc() I guess) with a new RuntimePermission. Without the >>> appropriate permission granted, gc() would simply be a no-op. >> >> I know very little about RuntimePermission. Who needs to be involved in >> creating >> a new one? > > It seems the core libraries group is responsible for anything in > java.lang, which both SecurityManager and RuntimePermission are: > > http://openjdk.java.net/groups/core-libs/ > > So presumably both the GC group and the core libraries group would have > to be ok with this change. If you guys are ok with this in principle, I > can coordinate getting approval from the core-libs group via their > mailing list. I would also need a sponsor -- I don't know if they would > be from gc-dev or core-libs or both. > > Documentation like this one would have to be updated as well -- if this > is part of the JDK source then that is easy enough: > > http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html > > > Cheers, > Raman From john.cuthbertson at sun.com Thu Apr 22 12:37:37 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Thu, 22 Apr 2010 19:37:37 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6819061: G1: eliminate serial Other times that are proportional to the collection set length; ... Message-ID: <20100422193740.C74144466F@hg.openjdk.java.net> Changeset: 1316cec51b4d Author: johnc Date: 2010-04-22 10:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1316cec51b4d 6819061: G1: eliminate serial Other times that are proportional to the collection set length 6871109: G1: remove the concept of the scan only prefix Summary: Removed scan only regions and associated code. The young portion of the collection set is now constructed incrementally - when a young region is retired as the current allocation region it is added to the collection set. Reviewed-by: apetrusenko, iveresov, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/services/g1MemoryPool.cpp From jon.masamitsu at oracle.com Thu Apr 22 17:35:24 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 22 Apr 2010 17:35:24 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BD07854.1020903@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> Message-ID: <4BD0EB4C.7090703@oracle.com> Raman, In hotspot code in share/vm/prims/jvm.cpp there is an entry JVM_ENTRY_NO_ENV(void, JVM_GC(void)) JVMWrapper("JVM_GC"); if (!DisableExplicitGC) { Universe::heap()->collect(GCCause::_java_lang_system_gc); } JVM_END The VM change you would need would be to add an entry (or logical equivalent however you would choose to implement it) which would not check DisableExplicitGC? Maybe something like JVM_GC_GRANTED (or whatever). On the Java side you would make the check to see if the new RuntimePermission has been granted before calling the JVM_GC_GRANTED()? Is the JVM_GC_GRANTED() entry the change you would want us to accept? Jon On 4/22/10 9:24 AM, Raman Gupta wrote: > On 04/22/2010 02:22 AM, Jon Masamitsu wrote: >> On 4/21/10 4:19 PM, Raman Gupta wrote: >>> I am not suggesting any new API at this time -- I mentioned it only as >>> a pie-in-the-sky kind of thing. >>> >>> My current suggestion is simply to gate System.gc() (or actually >>> Runtime.gc() I guess) with a new RuntimePermission. Without the >>> appropriate permission granted, gc() would simply be a no-op. >> >> I know very little about RuntimePermission. Who needs to be involved in >> creating >> a new one? > > It seems the core libraries group is responsible for anything in > java.lang, which both SecurityManager and RuntimePermission are: > > http://openjdk.java.net/groups/core-libs/ > > So presumably both the GC group and the core libraries group would > have to be ok with this change. If you guys are ok with this in > principle, I can coordinate getting approval from the core-libs group > via their mailing list. I would also need a sponsor -- I don't know if > they would be from gc-dev or core-libs or both. > > Documentation like this one would have to be updated as well -- if > this is part of the JDK source then that is easy enough: > > http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html > > > Cheers, > Raman From rocketraman at fastmail.fm Thu Apr 22 19:09:38 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Thu, 22 Apr 2010 22:09:38 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BD0EB4C.7090703@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> Message-ID: <4BD10162.7050206@fastmail.fm> Forgive my ignorance as this is my first foray into the internals of the java JDK/JVM. Here is my (probably wrong) understanding: The JDK contains: src/share/classes/java/lang/Runtime.java src/share/native/java/lang/Runtime.c and presumably all VMs (such as the hotspot VM) must implement the method which is called from Runtime.c: JVM_GC(void); Now having looked at the code, it seems to me this change would make more sense at the JDK level rather than the VM level (and if so, I guess I'm on the wrong mailing list). My naiive implementation would be to 1) leave the JVM implementation alone (including the check for DisableExplicitGC flag), and 2) in Runtime.java, rename the existing gc() method to a private native method called gcImpl() or something like that. Modify Runtime.c accordingly. 3) in Runtime.java, reimplement gc() to check if RuntimePermission("explicitGC") is granted to the caller. If it is, delegate to gcImpl() and return. End result should be to allow users to grant permissions to do explicit GCs regardless of VM. For Hotspot, the DisableExplicitGC flag is still the ultimate arbiter of whether the explicit GC is done or not, as it is now. I think this makes the most sense, and it is also backward compatible in that explicit GCs will never be silently enabled for Hotspot if DisableExplicitGC is specified. To take advantage of this change, users remove DisableExplicitGC setting, and add the appropriate permission to their own code. Cheers, Raman On 04/22/2010 08:35 PM, Jon Masamitsu wrote: > Raman, > > In hotspot code in share/vm/prims/jvm.cpp there is an entry > > > JVM_ENTRY_NO_ENV(void, JVM_GC(void)) > JVMWrapper("JVM_GC"); > if (!DisableExplicitGC) { > Universe::heap()->collect(GCCause::_java_lang_system_gc); > } > JVM_END > > > The VM change you would need would be to add > an entry (or logical equivalent however you would > choose to implement it) which would not check > DisableExplicitGC? Maybe something like > JVM_GC_GRANTED (or whatever). > > On the Java side you would make the check to > see if the new RuntimePermission has been > granted before calling the JVM_GC_GRANTED()? > > Is the JVM_GC_GRANTED() entry the change > you would want us to accept? > > Jon > > On 4/22/10 9:24 AM, Raman Gupta wrote: >> On 04/22/2010 02:22 AM, Jon Masamitsu wrote: >>> On 4/21/10 4:19 PM, Raman Gupta wrote: >>>> I am not suggesting any new API at this time -- I mentioned it only as >>>> a pie-in-the-sky kind of thing. >>>> >>>> My current suggestion is simply to gate System.gc() (or actually >>>> Runtime.gc() I guess) with a new RuntimePermission. Without the >>>> appropriate permission granted, gc() would simply be a no-op. >>> >>> I know very little about RuntimePermission. Who needs to be involved in >>> creating >>> a new one? >> >> It seems the core libraries group is responsible for anything in >> java.lang, which both SecurityManager and RuntimePermission are: >> >> http://openjdk.java.net/groups/core-libs/ >> >> So presumably both the GC group and the core libraries group would >> have to be ok with this change. If you guys are ok with this in >> principle, I can coordinate getting approval from the core-libs group >> via their mailing list. I would also need a sponsor -- I don't know if >> they would be from gc-dev or core-libs or both. >> >> Documentation like this one would have to be updated as well -- if >> this is part of the JDK source then that is easy enough: >> >> http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html >> >> >> Cheers, >> Raman > > From jon.masamitsu at oracle.com Thu Apr 22 20:13:22 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 22 Apr 2010 20:13:22 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BD10162.7050206@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> <4BD10162.7050206@fastmail.fm> Message-ID: <4BD11052.9010803@oracle.com> Raman, Given the plan you outlined below, what would be the behavior if an application does nothing about the RuntimePermission explicitGC? Would all explicit GC's be ignored? Jon On 4/22/10 7:09 PM, Raman Gupta wrote: > Forgive my ignorance as this is my first foray into the internals of > the java JDK/JVM. > > Here is my (probably wrong) understanding: > > The JDK contains: > src/share/classes/java/lang/Runtime.java > src/share/native/java/lang/Runtime.c > > and presumably all VMs (such as the hotspot VM) must implement the > method which is called from Runtime.c: > > JVM_GC(void); > > Now having looked at the code, it seems to me this change would make > more sense at the JDK level rather than the VM level (and if so, I > guess I'm on the wrong mailing list). My naiive implementation would > be to > > 1) leave the JVM implementation alone (including the check for > DisableExplicitGC flag), and > > 2) in Runtime.java, rename the existing gc() method to a private > native method called gcImpl() or something like that. Modify Runtime.c > accordingly. > > 3) in Runtime.java, reimplement gc() to check if > RuntimePermission("explicitGC") is granted to the caller. If it is, > delegate to gcImpl() and return. > > End result should be to allow users to grant permissions to do > explicit GCs regardless of VM. For Hotspot, the DisableExplicitGC flag > is still the ultimate arbiter of whether the explicit GC is done or > not, as it is now. I think this makes the most sense, and it is also > backward compatible in that explicit GCs will never be silently > enabled for Hotspot if DisableExplicitGC is specified. > > To take advantage of this change, users remove DisableExplicitGC > setting, and add the appropriate permission to their own code. > > Cheers, > Raman > > > On 04/22/2010 08:35 PM, Jon Masamitsu wrote: >> Raman, >> >> In hotspot code in share/vm/prims/jvm.cpp there is an entry >> >> >> JVM_ENTRY_NO_ENV(void, JVM_GC(void)) >> JVMWrapper("JVM_GC"); >> if (!DisableExplicitGC) { >> Universe::heap()->collect(GCCause::_java_lang_system_gc); >> } >> JVM_END >> >> >> The VM change you would need would be to add >> an entry (or logical equivalent however you would >> choose to implement it) which would not check >> DisableExplicitGC? Maybe something like >> JVM_GC_GRANTED (or whatever). >> >> On the Java side you would make the check to >> see if the new RuntimePermission has been >> granted before calling the JVM_GC_GRANTED()? >> >> Is the JVM_GC_GRANTED() entry the change >> you would want us to accept? >> >> Jon >> >> On 4/22/10 9:24 AM, Raman Gupta wrote: >>> On 04/22/2010 02:22 AM, Jon Masamitsu wrote: >>>> On 4/21/10 4:19 PM, Raman Gupta wrote: >>>>> I am not suggesting any new API at this time -- I mentioned it >>>>> only as >>>>> a pie-in-the-sky kind of thing. >>>>> >>>>> My current suggestion is simply to gate System.gc() (or actually >>>>> Runtime.gc() I guess) with a new RuntimePermission. Without the >>>>> appropriate permission granted, gc() would simply be a no-op. >>>> >>>> I know very little about RuntimePermission. Who needs to be >>>> involved in >>>> creating >>>> a new one? >>> >>> It seems the core libraries group is responsible for anything in >>> java.lang, which both SecurityManager and RuntimePermission are: >>> >>> http://openjdk.java.net/groups/core-libs/ >>> >>> So presumably both the GC group and the core libraries group would >>> have to be ok with this change. If you guys are ok with this in >>> principle, I can coordinate getting approval from the core-libs group >>> via their mailing list. I would also need a sponsor -- I don't know if >>> they would be from gc-dev or core-libs or both. >>> >>> Documentation like this one would have to be updated as well -- if >>> this is part of the JDK source then that is easy enough: >>> >>> http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html >>> >>> >>> >>> Cheers, >>> Raman >> >> From rocketraman at fastmail.fm Thu Apr 22 23:11:08 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Fri, 23 Apr 2010 02:11:08 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BD11052.9010803@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> <4BD10162.7050206@fastmail.fm> <4BD11052.9010803@oracle.com> Message-ID: <4BD139FC.6020504@fastmail.fm> My understanding is that by default there is no security manager installed, therefore the behavior would be exactly the same as it is today. However, if a security manager *is* installed, either by the user themselves, or by a container such as an application server, or environments restricted by default such as applets, then the security policy in effect would govern the behavior. In this case, if the security policy does not grant the explicitGC permission, either by default or by user (or vendor) modification, then yes, all explicit GCs will be ignored. With the amount of abuse of System.gc() out there I'm not so sure that's a bad thing. If there is code that requires it (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6200079 for example), the default policy can be modified to allow it by default. The release notes should suffice for container vendors and the like. Cheers, Raman On 04/22/2010 11:13 PM, Jon Masamitsu wrote: > Raman, > > Given the plan you outlined below, what would be the behavior if > an application does nothing about the RuntimePermission > explicitGC? Would all explicit GC's be ignored? > > Jon > > On 4/22/10 7:09 PM, Raman Gupta wrote: >> Forgive my ignorance as this is my first foray into the internals of >> the java JDK/JVM. >> >> Here is my (probably wrong) understanding: >> >> The JDK contains: >> src/share/classes/java/lang/Runtime.java >> src/share/native/java/lang/Runtime.c >> >> and presumably all VMs (such as the hotspot VM) must implement the >> method which is called from Runtime.c: >> >> JVM_GC(void); >> >> Now having looked at the code, it seems to me this change would make >> more sense at the JDK level rather than the VM level (and if so, I >> guess I'm on the wrong mailing list). My naiive implementation would >> be to >> >> 1) leave the JVM implementation alone (including the check for >> DisableExplicitGC flag), and >> >> 2) in Runtime.java, rename the existing gc() method to a private >> native method called gcImpl() or something like that. Modify Runtime.c >> accordingly. >> >> 3) in Runtime.java, reimplement gc() to check if >> RuntimePermission("explicitGC") is granted to the caller. If it is, >> delegate to gcImpl() and return. >> >> End result should be to allow users to grant permissions to do >> explicit GCs regardless of VM. For Hotspot, the DisableExplicitGC flag >> is still the ultimate arbiter of whether the explicit GC is done or >> not, as it is now. I think this makes the most sense, and it is also >> backward compatible in that explicit GCs will never be silently >> enabled for Hotspot if DisableExplicitGC is specified. >> >> To take advantage of this change, users remove DisableExplicitGC >> setting, and add the appropriate permission to their own code. >> >> Cheers, >> Raman >> >> >> On 04/22/2010 08:35 PM, Jon Masamitsu wrote: >>> Raman, >>> >>> In hotspot code in share/vm/prims/jvm.cpp there is an entry >>> >>> >>> JVM_ENTRY_NO_ENV(void, JVM_GC(void)) >>> JVMWrapper("JVM_GC"); >>> if (!DisableExplicitGC) { >>> Universe::heap()->collect(GCCause::_java_lang_system_gc); >>> } >>> JVM_END >>> >>> >>> The VM change you would need would be to add >>> an entry (or logical equivalent however you would >>> choose to implement it) which would not check >>> DisableExplicitGC? Maybe something like >>> JVM_GC_GRANTED (or whatever). >>> >>> On the Java side you would make the check to >>> see if the new RuntimePermission has been >>> granted before calling the JVM_GC_GRANTED()? >>> >>> Is the JVM_GC_GRANTED() entry the change >>> you would want us to accept? >>> >>> Jon >>> >>> On 4/22/10 9:24 AM, Raman Gupta wrote: >>>> On 04/22/2010 02:22 AM, Jon Masamitsu wrote: >>>>> On 4/21/10 4:19 PM, Raman Gupta wrote: >>>>>> I am not suggesting any new API at this time -- I mentioned it >>>>>> only as >>>>>> a pie-in-the-sky kind of thing. >>>>>> >>>>>> My current suggestion is simply to gate System.gc() (or actually >>>>>> Runtime.gc() I guess) with a new RuntimePermission. Without the >>>>>> appropriate permission granted, gc() would simply be a no-op. >>>>> >>>>> I know very little about RuntimePermission. Who needs to be >>>>> involved in >>>>> creating >>>>> a new one? >>>> >>>> It seems the core libraries group is responsible for anything in >>>> java.lang, which both SecurityManager and RuntimePermission are: >>>> >>>> http://openjdk.java.net/groups/core-libs/ >>>> >>>> So presumably both the GC group and the core libraries group would >>>> have to be ok with this change. If you guys are ok with this in >>>> principle, I can coordinate getting approval from the core-libs group >>>> via their mailing list. I would also need a sponsor -- I don't know if >>>> they would be from gc-dev or core-libs or both. >>>> >>>> Documentation like this one would have to be updated as well -- if >>>> this is part of the JDK source then that is easy enough: >>>> >>>> http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html >>>> >>>> >>>> >>>> Cheers, >>>> Raman >>> >>> > From rocketraman at fastmail.fm Fri Apr 23 11:52:15 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Fri, 23 Apr 2010 14:52:15 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BD1B37E.8070902@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> <4BD10162.7050206@fastmail.fm> <4BD11052.9010803@oracle.com> <4BD139FC.6020504@fastmail.fm> <4BD1B37E.8070902@oracle.com> Message-ID: <4BD1EC5F.9040900@fastmail.fm> On 04/23/2010 10:49 AM, Jon Masamitsu wrote: > On 4/22/10 11:11 PM, Raman Gupta wrote: >> My understanding is that by default there is no security manager >> installed, therefore the behavior would be exactly the same as it is >> today. >> >> However, if a security manager *is* installed, either by the user >> themselves, or by a container such as an application server, or >> environments restricted by default such as applets, then the security >> policy in effect would govern the behavior. In this case, if the >> security policy does not grant the explicitGC permission, either by >> default or by user (or vendor) modification, then yes, all explicit >> GCs will be ignored. >> >> With the amount of abuse of System.gc() out there I'm not so sure >> that's a bad thing. If there is code that requires it (see >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6200079 for >> example), the default policy can be modified to allow it by default. >> The release notes should suffice for container vendors and the like. > > You're right that there is abuse of Systen.gc() :-) and we could > hide because the "nothing is guaranteed to happen" on a System.gc() > but it is a major change in behavior. That scares me. > > If the RuntimePermissions checking code could look to see if the VM > underneath had the JVM_GC_GRANTED() interface, then any VM > that wanted to could provide this additional service. I think that JVMTI > does something like that - you can get a list of the JVMTI capabilities > offered by the VM. I don't know if such a thing exists outside > JVMTI. And yes, other VM vendors need to be involved. If I understand you correctly, then Runtime.java/Runtime.c would check if the underlying VM had JVM_GC_GRANTED (a new interface). JVM_GC_GRANTED is like JVM_GC but DisableExplicitGC is not checked. If the "explicitGC" RuntimePermission was granted to the running code, and JVM_GC_GRANTED was available, then Runtime.java/Runtime.c call JVM_GC_GRANTED instead of JVM_GC. If that is right, then I'm not sure how that changes anything. The change of behavior we are concerned with is that where today an explicit GC *would* run, we would be changing the JDK in such a way, via RuntimePermission, that it *would not* run. JVM_GC_GRANTED does not seem to change this. One other proposal is to implement a JVM interface JVM_GC_PERMCHECK_ALLOWED returning a boolean. If this interface is available, and it returns true, then and only then will the "explicitGC" RuntimePermission be checked by the JDK. In this way, one will have to explicitly enable this permission check via a flag/setting at the JVM level. The default will of course be false. This would maintain the current behavior for both VMs that have not been updated to support JVM_GC_PERMCHECK_ALLOWED, and for VMs that do support it but where customers have not explicitly enabled it via flag or whatever. Cheers, Raman From tony.printezis at oracle.com Fri Apr 23 12:10:44 2010 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 23 Apr 2010 15:10:44 -0400 Subject: What influences young generation pause times? In-Reply-To: References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCF135D.8030808@oracle.com> Message-ID: <4BD1F0B4.8060302@oracle.com> Osvaldo, Osvaldo Doederlein wrote: > Tony, > > 2010/4/21 Tony Printezis > > > I'm not quite sure what you mean by big TLAB collection. You mean > to collect just the TLABs of a thread. You really cannot do that > without scanning the entire young gen to find all the references > into them. > > > I didn't know that, I was supposing that the TLAB would have a remset > for incoming references from the rest of the young gen. > Oh, no. Too expensive. There are too many references within the young gen, it could be too expensive to keep track of them. > > Let's assume you want to use something like RTSJ's scopes (and > let's say they are simplified and assume only one thread will > enter them, which removes a lot of the complexity associated with > RTSJ's scopes). Then the only way to be able to reclaim a scope > when you leave it is to ensure that there are no references from > outside the scope into it. You can ensure that this is the case by > introducing write barriers and throwing an exception if such a > reference is created (which is what the RTSJ does), but now a lot > of the existing code won't work correctly with this restriction. > So, you just cannot do what you're proposing without some extra costs. > > > To make my suggestion more clear, the intention is just enabling > something similar to RTSJ. While "inside" some scope, the program can > introduce references from old to new objects, as long as these refs > are all cleared when "exiting" the scope. By "request GC that will be > basically free" I didn't mean something identical to RTSJ (free() a > whole heap block), but only trigger the young-GC -- Here you are assuming that what you're referring to as a "young GC" will only touch the objects that just got allocated by that thread (and there'd be extra costs associated with ensuring that). Or did you really mean an actual young GC? Again, in the single-threaded case, this might work. It won't in the multi-threaded case: if each thread that completes a transaction triggers a young GC, then the system will be overwhelmed by young GCs. > at that time, all those young objects are unreachable. Except perhaps > a few objects that existed before entering the scope - not a problem, > they are all compacted in the beginning of the YG, so young-GC will be > only slightly slower than for zero live objects, no big deal. As I said, there's nothing "free" in GC. If you copy all the objects (as we do now), you have to copy the ones that existed when you entered the scope anyway. If you introduce a way to only copy the survivors of the objects that were created from inside the scope, you'd still have to scan the ones you didn't copy to find and update references to the objects you're moving. If you don't want to scan them, you'd have to maintain remembered sets. You might think that implementing something like what you're proposing is simple but, really, it's not. > (I'm also not wishing for real-time GC guarantees like in RTSJ.) > Good. :-) > > We have been working on, and thinking about GC, for a long time. > Trust me, if there was a way to do cheaply what you're proposing, > we would have done it a long time ago. With the semantics of Java > it's not straightforward. And, after many years of doing this > stuff, I can also assure you that nothing in GC it's "free". ;-) > > > I certainly believe this - I'm not suggesting anything that would be > really free. In all suggestions I would expect some hit in overall > throughput (thread-local young gens would have this cost because we > potentially increase the working set, so reduced cache efficiency > alone should more than offset the cycles saved in GC). And also because the concept of a thead-local object is not built-in the language. If we were doing Erlang, it'd be a different story... > In other cases - fine-grained explicit GC API + strict > threading/allocation behavior required for near-instant young GC - the > cost is programming complexity. These costs would be fine for a great > many apps. > > Let's put it differently: why not adding a simple API like I suggested > (trigger only young-GC, perhaps with a parameter to only do that if > the young gen has less than some % of free space)? I'd expect this to > be trivial to implement. It will definitely not be complicated to implement. > Maybe we could have this in some sun.* package, and only in > non-release builds for extra protection. Let people kick the tires and > give you feedback - whether this produces significant benefits for > some apps. There are no plans to do this at the moment. In all honesty, we all have our hands full right now and such an API would be low in our (very long) priority list. Tony > > > > > for a particular thread, it does not mean that it's also > good for > the rest. Additionally, I would be willing to bet money > that if we > provided such an API, library writers will abuse it > thinking that > "hey, the end of this library call will be a great time to do a > young GC!", without taking into consideration that many other > threads could be doing something totally different at the same > time (we've seen way too many libraries that call System.gc() > already...). > > > This is true, but I guess the problem could be handled by the > Security manager and/or VM options, maybe allowing only > certain packages to induce GC in any way. There is precedent > for that (-XX:+DisableExplicitGC, and default configuration of > app servers to use that option). The problem exisits but it's > not new in any "lightweight GC API" proposal - even to current > date I sometimes find some app code that invokes Good Old > System.gc(). Please let's not use the "developers will shoot > themselves in the foot" argument, to not provide a solution > for a very painful problem. :) > > On the contrary, our mission is to prevent developers from > shooting themselves in the foot. :-) > > Tony > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 oracle.com Fri Apr 23 12:36:26 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 23 Apr 2010 12:36:26 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BD1EC5F.9040900@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> <4BD10162.7050206@fastmail.fm> <4BD11052.9010803@oracle.com> <4BD139FC.6020504@fastmail.fm> <4BD1B37E.8070902@oracle.com> <4BD1EC5F.9040900@fastmail.fm> Message-ID: <4BD1F6BA.7070703@oracle.com> On 4/23/10 11:52 AM, Raman Gupta wrote: > ... > > If I understand you correctly, then Runtime.java/Runtime.c would check > if the underlying VM had JVM_GC_GRANTED (a new interface). > JVM_GC_GRANTED is like JVM_GC but DisableExplicitGC is not checked. If > the "explicitGC" RuntimePermission was granted to the running code, > and JVM_GC_GRANTED was available, then Runtime.java/Runtime.c call > JVM_GC_GRANTED instead of JVM_GC. > > If that is right, then I'm not sure how that changes anything. The > change of behavior we are concerned with is that where today an > explicit GC *would* run, we would be changing the JDK in such a way, > via RuntimePermission, that it *would not* run. JVM_GC_GRANTED does > not seem to change this. I did leave out a part. The customer would have to use -XX:+DisableExplicitGC to disallow System.gc() generally. Then the JVM_GC_GRANTED() would be called by a thread that had the permissions. If the new RuntimePermission and JVM_GC_GRANTED() were implemented but not used by any application, then everything behaves the same as today. An application that wants to do System.gc() while locking others out would use -XX:+DisableExplicitGC and would add the code to use RuntimePermission and JVM_GC_GRANTED() and thus get the System.gc() even though DisableExplicitGC is set. > > One other proposal is to implement a JVM interface > JVM_GC_PERMCHECK_ALLOWED returning a boolean. If this interface is > available, and it returns true, then and only then will the > "explicitGC" RuntimePermission be checked by the JDK. In this way, one > will have to explicitly enable this permission check via a > flag/setting at the JVM level. The default will of course be false. > This would maintain the current behavior for both VMs that have not > been updated to support JVM_GC_PERMCHECK_ALLOWED, and for VMs that do > support it but where customers have not explicitly enabled it via flag > or whatever. I don't understand this suggestion. > > Cheers, > Raman From rocketraman at fastmail.fm Fri Apr 23 13:24:53 2010 From: rocketraman at fastmail.fm (Raman Gupta) Date: Fri, 23 Apr 2010 16:24:53 -0400 Subject: What influences young generation pause times? In-Reply-To: <4BD1F6BA.7070703@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> <4BD10162.7050206@fastmail.fm> <4BD11052.9010803@oracle.com> <4BD139FC.6020504@fastmail.fm> <4BD1B37E.8070902@oracle.com> <4BD1EC5F.9040900@fastmail.fm> <4BD1F6BA.7070703@oracle.com> Message-ID: <4BD20215.9070506@fastmail.fm> On 04/23/2010 03:36 PM, Jon Masamitsu wrote: > On 4/23/10 11:52 AM, Raman Gupta wrote: > I did leave out a part. The customer would have to use > -XX:+DisableExplicitGC to disallow System.gc() generally. Then the > JVM_GC_GRANTED() would be called by a thread that had the > permissions. > > If the new RuntimePermission and JVM_GC_GRANTED() were implemented > but not used by any application, then everything behaves the same > as today. > > An application that wants to do System.gc() while locking others > out would use -XX:+DisableExplicitGC and would add the code to use > RuntimePermission and JVM_GC_GRANTED() and thus get the System.gc() > even though DisableExplicitGC is set. Ahh, I think I see what you are saying: if RuntimePermission "explicitGC" is granted, then JVM_GC_GRANTED // GC runs regardless of DisableExplicitGC else JVM_GC // GC runs only if DisableExplicitGC not set I think the semantic change in "DisableExplicitGC" might be a little confusing for users. It might be simpler for users to understand if a new flag like "DisableExplicitGCNonGranted" is added instead (default is false): JVM_ENTRY_NO_ENV(void, JVM_GC_GRANTED(void)) JVMWrapper("JVM_GC_GRANTED"); if (!DisableExplicitGC) { Universe::heap()->collect(GCCause::_java_lang_system_gc); } JVM_END JVM_ENTRY_NO_ENV(void, JVM_GC(void)) JVMWrapper("JVM_GC"); if (!DisableExplicitGC && !DisableExplicitGCNonGranted) { Universe::heap()->collect(GCCause::_java_lang_system_gc); } JVM_END This also allows for the possibility to turn off all explicit GC at the JVM level regardless -- which may be useful in certain situations. To take advantage of this functionality then, users would grant their code the new RuntimePermission, and change their use of DisableExplicitGC to DisableExplicitGCNonGranted. >> One other proposal is to implement a JVM interface >> JVM_GC_PERMCHECK_ALLOWED returning a boolean. If this interface is >> available, and it returns true, then and only then will the >> "explicitGC" RuntimePermission be checked by the JDK. In this way, one >> will have to explicitly enable this permission check via a >> flag/setting at the JVM level. The default will of course be false. >> This would maintain the current behavior for both VMs that have not >> been updated to support JVM_GC_PERMCHECK_ALLOWED, and for VMs that do >> support it but where customers have not explicitly enabled it via flag >> or whatever. > > I don't understand this suggestion. Never mind, I like your approach better. Cheers, Raman From opinali at gmail.com Fri Apr 23 13:38:06 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Fri, 23 Apr 2010 17:38:06 -0300 Subject: What influences young generation pause times? In-Reply-To: <4BD1F0B4.8060302@oracle.com> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCF135D.8030808@oracle.com> <4BD1F0B4.8060302@oracle.com> Message-ID: Hi Tony, 2010/4/23 Tony Printezis > To make my suggestion more clear, the intention is just enabling something > similar to RTSJ. While "inside" some scope, the program can introduce > references from old to new objects, as long as these refs are all cleared > when "exiting" the scope. By "request GC that will be basically free" I > didn't mean something identical to RTSJ (free() a whole heap block), but > only trigger the young-GC -- > Here you are assuming that what you're referring to as a "young GC" will > only touch the objects that just got allocated by that thread (and there'd > be extra costs associated with ensuring that). Or did you really mean an > actual young GC? Again, in the single-threaded case, this might work. It > won't in the multi-threaded case: if each thread that completes a > transaction triggers a young GC, then the system will be overwhelmed by > young GCs. > I'm not ignoring the cost of marking - the discussion started because copying alone can be a significant fraction of the total cost of generational GC. If the young-gen is basically empty of live objects, I think we have significant speedup compared to an average young-GC (that doesn't necessarily happen in the "perfect" time, with lots of live young objects). But I see now that the idea doesn't work at all for nontrivial multithreaded apps. > at that time, all those young objects are unreachable. Except perhaps a >> few objects that existed before entering the scope - not a problem, they are >> all compacted in the beginning of the YG, so young-GC will be only slightly >> slower than for zero live objects, no big deal. >> > As I said, there's nothing "free" in GC. If you copy all the objects (as we > do now), you have to copy the ones that existed when you entered the scope > anyway. If you introduce a way to only copy the survivors of the objects > that were created from inside the scope, you'd still have to scan the ones > you didn't copy to find and update references to the objects you're moving. > If you don't want to scan them, you'd have to maintain remembered sets. You > might think that implementing something like what you're proposing is simple > but, really, it's not. > My assumption here is that the old generation is very stable - the program loops in a cycle of phases that create lots of new objects, then in the end of each cycle virtually all these objects die, they are collected, goto next cycle. Any objects that you may have in the YG initially (before the program stabilizes in such loop) would be promoted to the old gen after a few collections. The app developer would measure the worst-case allocation volume for each cycle, and size the young-gen so that volume fits. > Let's put it differently: why not adding a simple API like I suggested >> (trigger only young-GC, perhaps with a parameter to only do that if the >> young gen has less than some % of free space)? I'd expect this to be trivial >> to implement. >> > > It will definitely not be complicated to implement. > >> Maybe we could have this in some sun.* package, and only in non-release >> builds for extra protection. Let people kick the tires and give you feedback >> - whether this produces significant benefits for some apps. >> > There are no plans to do this at the moment. In all honesty, we all have > our hands full right now and such an API would be low in our (very long) > priority list. > This looks like an interesting OpenJDK experiment. Maybe I should find some time to write a patch, then test a couple apps that I think that would benefit from the idea. A+ Osvaldo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100423/bf64a639/attachment-0001.html -------------- next part -------------- _______________________________________________ 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 oracle.com Mon Apr 26 14:09:00 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 26 Apr 2010 14:09:00 -0700 Subject: What influences young generation pause times? In-Reply-To: <4BD20215.9070506@fastmail.fm> References: <4BCDB470.8090102@oracle.com> <4BCDEE6F.8030807@oracle.com> <4BCE224A.1000306@fastmail.fm> <4BCF7846.5080701@oracle.com> <4BCF7DD2.5000104@fastmail.fm> <4BCF82AA.4040804@oracle.com> <4BCF881A.9050309@fastmail.fm> <4BCFEB2E.20108@oracle.com> <4BD07854.1020903@fastmail.fm> <4BD0EB4C.7090703@oracle.com> <4BD10162.7050206@fastmail.fm> <4BD11052.9010803@oracle.com> <4BD139FC.6020504@fastmail.fm> <4BD1B37E.8070902@oracle.com> <4BD1EC5F.9040900@fastmail.fm> <4BD1F6BA.7070703@oracle.com> <4BD20215.9070506@fastmail.fm> Message-ID: <4BD600EC.5050108@oracle.com> On 04/23/10 13:24, Raman Gupta wrote: > On 04/23/2010 03:36 PM, Jon Masamitsu wrote: >> On 4/23/10 11:52 AM, Raman Gupta wrote: >> I did leave out a part. The customer would have to use >> -XX:+DisableExplicitGC to disallow System.gc() generally. Then the >> JVM_GC_GRANTED() would be called by a thread that had the >> permissions. >> >> If the new RuntimePermission and JVM_GC_GRANTED() were implemented >> but not used by any application, then everything behaves the same >> as today. > > >> An application that wants to do System.gc() while locking others >> out would use -XX:+DisableExplicitGC and would add the code to use >> RuntimePermission and JVM_GC_GRANTED() and thus get the System.gc() >> even though DisableExplicitGC is set. > > Ahh, I think I see what you are saying: > > if RuntimePermission "explicitGC" is granted, then > JVM_GC_GRANTED // GC runs regardless of DisableExplicitGC > else > JVM_GC // GC runs only if DisableExplicitGC not set > > I think the semantic change in "DisableExplicitGC" might be a little > confusing for users. It might be simpler for users to understand if a > new flag like "DisableExplicitGCNonGranted" is added instead (default > is false): Perhaps it would be confusing for the user. Any program today would continue to behave as it currently does. The user would have to take some action to grant RuntimePermission "explicitGC" so they should not be surprised. I can see the point of the new flag "DisableExplicitGCNonGranted". It's just that we have so many flags already, it would be nice to not introduce yet another one. > > JVM_ENTRY_NO_ENV(void, JVM_GC_GRANTED(void)) > JVMWrapper("JVM_GC_GRANTED"); > if (!DisableExplicitGC) { > Universe::heap()->collect(GCCause::_java_lang_system_gc); > } > JVM_END > > JVM_ENTRY_NO_ENV(void, JVM_GC(void)) > JVMWrapper("JVM_GC"); > if (!DisableExplicitGC && !DisableExplicitGCNonGranted) { > Universe::heap()->collect(GCCause::_java_lang_system_gc); > } > JVM_END > > This also allows for the possibility to turn off all explicit GC at > the JVM level regardless -- which may be useful in certain situations. > > To take advantage of this functionality then, users would grant their > code the new RuntimePermission, and change their use of > DisableExplicitGC to DisableExplicitGCNonGranted. Perhaps we could obsolete DisableExplicitGC and just use DisableExplicitGCNonGranted in the future. We'd probably only have to support DisableExplicitGC as an alias for DisableExplicitGCNonGranted for 15 or 20 years :-). > >>> One other proposal is to implement a JVM interface >>> JVM_GC_PERMCHECK_ALLOWED returning a boolean. If this interface is >>> available, and it returns true, then and only then will the >>> "explicitGC" RuntimePermission be checked by the JDK. In this way, one >>> will have to explicitly enable this permission check via a >>> flag/setting at the JVM level. The default will of course be false. >>> This would maintain the current behavior for both VMs that have not >>> been updated to support JVM_GC_PERMCHECK_ALLOWED, and for VMs that do >>> support it but where customers have not explicitly enabled it via flag >>> or whatever. >> >> I don't understand this suggestion. > > Never mind, I like your approach better. > > Cheers, > Raman From tony.printezis at oracle.com Mon Apr 26 19:38:27 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Tue, 27 Apr 2010 02:38:27 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 32 new changesets Message-ID: <20100427023935.453A94419F@hg.openjdk.java.net> Changeset: a2ea687fdc7c Author: coleenp Date: 2010-03-31 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a2ea687fdc7c 6938627: Make temporary directory use property java.io.tmpdir when specified Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. Reviewed-by: dholmes, kamg ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0fd6320854d3 Author: jcoomes Date: 2010-04-02 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0fd6320854d3 Merge Changeset: 6ccd32c284ac Author: kamg Date: 2010-04-07 12:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6ccd32c284ac Merge Changeset: e4c77b879561 Author: tonyp Date: 2010-04-09 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e4c77b879561 Merge Changeset: ed4f78aa9282 Author: twisti Date: 2010-04-06 13:39 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ed4f78aa9282 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops. Reviewed-by: kvn, never ! src/share/vm/code/codeCache.cpp Changeset: 0dc88ad3244e Author: kvn Date: 2010-04-06 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0dc88ad3244e 6940677: Use 64 bytes chunk copy for arraycopy on Sparc Summary: For large arrays we should use 64 bytes chunks copy. Reviewed-by: twisti ! src/cpu/sparc/vm/stubGenerator_sparc.cpp Changeset: 6476042f815c Author: kvn Date: 2010-04-07 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6476042f815c 6940701: Don't align loops in stubs for Niagara sparc Summary: Don't align loops in stubs for Niagara sparc since NOPs are expensive. Reviewed-by: twisti, never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/globals.hpp Changeset: b9d85fcdf743 Author: kvn Date: 2010-04-07 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b9d85fcdf743 6940733: allocate non static oop fields in super and sub classes together Summary: Use FieldsAllocationStyle=2 to allocate non static oop fields in super and sub classes together Reviewed-by: twisti ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9e321dcfa5b7 Author: kvn Date: 2010-04-07 12:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9e321dcfa5b7 6940726: Use BIS instruction for allocation prefetch on Sparc Summary: Use BIS instruction for allocation prefetch on Sparc Reviewed-by: twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp Changeset: 93767e6a2dfd Author: twisti Date: 2010-04-08 10:55 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/93767e6a2dfd 6941529: SharedRuntime::raw_exception_handler_for_return_address must reset thread MethodHandle flag Summary: During testing a bug was hit when an exception returned to the interpreter and the SP was wrong. Reviewed-by: kvn, never ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0a43776437b6 Author: iveresov Date: 2010-04-08 12:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0a43776437b6 6942223: c1 64 bit fixes Summary: This fixes lir_cmp_l2i on x64 and sparc 64bit, and the debug info generation. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 213fbcf54799 Author: jrose Date: 2010-04-08 17:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/213fbcf54799 Merge Changeset: fc3cd2277dc7 Author: jrose Date: 2010-04-13 13:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fc3cd2277dc7 Merge Changeset: 3f12a94552cc Author: mikejwre Date: 2010-04-08 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3f12a94552cc Added tag jdk7-b88 for changeset 4b60f23c4223 ! .hgtags Changeset: 5b29c2368d93 Author: lana Date: 2010-04-08 15:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5b29c2368d93 Merge ! src/share/vm/opto/type.cpp Changeset: 15836273ac24 Author: lana Date: 2010-04-13 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/15836273ac24 Merge Changeset: 4c78b7c16824 Author: trims Date: 2010-04-15 19:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4c78b7c16824 6944398: Bump the HS18 build number to 03 Summary: Update the HS18 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e16cca0aa5e1 Author: trims Date: 2010-04-15 19:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e16cca0aa5e1 Merge Changeset: 25f53b53aaa3 Author: trims Date: 2010-04-15 19:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/25f53b53aaa3 Added tag hs18-b02 for changeset 4b60f23c4223 ! .hgtags Changeset: 765578777b6e Author: mikejwre Date: 2010-04-15 13:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/765578777b6e Added tag jdk7-b89 for changeset 15836273ac24 ! .hgtags Changeset: 605c9707a766 Author: trims Date: 2010-04-20 21:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/605c9707a766 Merge ! .hgtags Changeset: ef74d6d1ac1e Author: never Date: 2010-04-14 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ef74d6d1ac1e 6938026: C2 compiler fails in Node::rematerialize()const Reviewed-by: twisti ! src/share/vm/opto/parse1.cpp Changeset: 9f5b60a14736 Author: never Date: 2010-04-15 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9f5b60a14736 6939930: exception unwind changes in 6919934 hurts compilation speed Reviewed-by: twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: f9271ff9d324 Author: twisti Date: 2010-04-15 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f9271ff9d324 6941224: Improved stack overflow handling for Zero Summary: Adding stack overflow checking to Shark brought to light a bunch of deficiencies in Zero's stack overflow code. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/fakeStubFrame_zero.hpp ! src/cpu/zero/vm/interpreterFrame_zero.hpp ! src/cpu/zero/vm/interpreterRT_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp ! src/share/vm/includeDB_zero Changeset: badea972a310 Author: twisti Date: 2010-04-16 00:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/badea972a310 Merge Changeset: a9584793da0f Author: twisti Date: 2010-04-15 03:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a9584793da0f 6944028: 6940701 broke Zero Summary: The fix for 6940701 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp Changeset: d32d2a2f62cd Author: twisti Date: 2010-04-16 02:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d32d2a2f62cd Merge Changeset: aa9c266de52a Author: twisti Date: 2010-04-16 05:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/aa9c266de52a 6944473: 6941224 misses new files Summary: Two new files are missing in the push for 6941224. Reviewed-by: twisti Contributed-by: Gary Benson + src/cpu/zero/vm/stack_zero.cpp + src/cpu/zero/vm/stack_zero.inline.hpp Changeset: c544d979f886 Author: twisti Date: 2010-04-19 02:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c544d979f886 6944503: Improved Zero crash dump Summary: With Zero on a GC crash the stack was dumped differently to other crashes. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: bc32f286fae0 Author: never Date: 2010-04-20 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bc32f286fae0 6945219: minor SA fixes Reviewed-by: twisti ! agent/src/os/linux/ps_core.c ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeDisassembler.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/SignatureIterator.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FrameWrapper.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Assert.java Changeset: ba07d5be2d51 Author: jrose Date: 2010-04-21 01:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ba07d5be2d51 Merge Changeset: 454ff03c0daf Author: tonyp Date: 2010-04-26 18:01 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/454ff03c0daf Merge From john.cuthbertson at sun.com Tue Apr 27 20:39:33 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Wed, 28 Apr 2010 03:39:33 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6946056: assert((intptr_t) sp()<=(intptr_t) result, "result must>=than stack pointer"), frame_x86.cpp:295 Message-ID: <20100428033935.309A8441DB@hg.openjdk.java.net> Changeset: 615a9d95d265 Author: johnc Date: 2010-04-27 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/615a9d95d265 6946056: assert((intptr_t) sp()<=(intptr_t) result,"result must>=than stack pointer"), frame_x86.cpp:295 Summary: frame::interpreter_frame_monitor_end() will spuriously assert for a frame that spans 0x80000000. Cast values to intptr_t* (rather than intptr_t) so that an unsigned pointer compare is performed. Reviewed-by: never, jcoomes, pbk ! src/cpu/x86/vm/frame_x86.cpp From yamauchi at google.com Wed Apr 28 13:37:31 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Wed, 28 Apr 2010 13:37:31 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: References: <4BA0087A.2040006@Sun.COM> <4BA3AE88.3090002@sun.com> <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> Message-ID: Jon, Here's an update based on what we discussed: http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.02/ The summary of the latest changes is that 1. On minor collections, the free ratio is computed based on the young gen heap, rather than both the young gen and the old gen heaps. 2. When -XX:-UseAdaptiveSizePolicy, the free ratio based resizing happens on normal collections, rather than just on System.gc() when -XX:+PSResizeByFreeRatioWithSystemGC. Hiroshi On Tue, Apr 13, 2010 at 11:21 AM, Hiroshi Yamauchi wrote: > Hi Jon, > > I finally got to this. Here's the webrev for a second version based on > our discussion (thanks to Chuck Rasbold): > > ?http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ > > The summary of change is that the logic for expansion based on > MinHeapFreeRatio was added and only the flag for the System.gc was > retained (and renamed to PSResizeByFreeRatioWithSystemGC.) > > Thanks, > Hiroshi > > > On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu wrote: >> On 03/31/10 11:26, Hiroshi Yamauchi wrote: >>> >>> >>> ... >>> >>> I think we agree that it's a good idea to try to shrink the heap in >>> response to System.gc() in such a scenario/app. >> >> Yes on the shrinking on a System.gc() and perhaps for symmetry also >> expanding >> a small heap to MinFreeHeapRatio? ?UseAdaptiveSizePolicy will shrink the >> heap >> down during periods of low activity and it might be useful to swiftly expand >> the >> heap on a System.gc(). >>> >>> Since we are talking about a setting where the free ratio flags takes >>> precedence over the psAdaptiveSizePolicy's throughput goals, the suggested >>> logic in the original webrev is perhaps not so terrible? If so, I suppose >>> the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with that >>> because it can shrink the heap regardless of the throughput goal. It may >>> make sense to remove UseFreeRatioForParallelGC and keep >>> UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it happen >>> inside psAdaptiveSizePolicy instead, the current webrev does not work. >>> >> I like the structure of the original webrev with regard to the logic for >> using FreeRation. ?It's simpler than embedding it in the >> PSAdaptivesizePolicy. >> >> >> 243 ? ? if (UseFreeRatioOnlyInSystemGCForParallelGC && >> 245 ? ? ? ? ? gc_cause == GCCause::_java_lang_system_gc)) { >> ? ? ? ? ?compute_new_size(); ?<<<<<<<< ?generalization of >> ? ? ? ? ? ? ?<<<<<<<< ?try_to_shrink_by_free_ratio() >> 248 ? ? } else { >> ? ? ? ? ?use current UseAdaptiveSizePolicy >> ? ? ? ?} >> >> >> >> >> > From john.coomes at oracle.com Wed Apr 28 19:02:50 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Apr 2010 02:02:50 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6888953: some calls to function-like macros are missing semicolons Message-ID: <20100429020252.3719C44273@hg.openjdk.java.net> Changeset: cff162798819 Author: jcoomes Date: 2009-10-11 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cff162798819 6888953: some calls to function-like macros are missing semicolons Reviewed-by: pbk, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/utilities/xmlstream.cpp From john.coomes at oracle.com Wed Apr 28 21:01:32 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Apr 2010 04:01:32 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6888954: argument formatting for assert() and friends Message-ID: <20100429040134.4EBFD44297@hg.openjdk.java.net> Changeset: f03d0a26bf83 Author: jcoomes Date: 2010-04-22 13:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f03d0a26bf83 6888954: argument formatting for assert() and friends Reviewed-by: kvn, twisti, apetrusenko, never, dcubed ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp + test/runtime/6888954/vmerrors.sh From jon.masamitsu at oracle.com Thu Apr 29 13:58:14 2010 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 29 Apr 2010 13:58:14 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: References: <4BA0087A.2040006@Sun.COM> <4BA3AE88.3090002@sun.com> <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> Message-ID: <4BD9F2E6.3090404@oracle.com> Hiroshi, These changes are what I was expecting after we had talked. I still have to look at the details but may not get to those for a couple of days. Jon On 04/28/10 13:37, Hiroshi Yamauchi wrote: > Jon, > > Here's an update based on what we discussed: > > http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.02/ > > The summary of the latest changes is that > > 1. On minor collections, the free ratio is computed based on the young > gen heap, rather than both the young gen and the old gen heaps. > > 2. When -XX:-UseAdaptiveSizePolicy, the free ratio based resizing > happens on normal collections, rather than just on System.gc() when > -XX:+PSResizeByFreeRatioWithSystemGC. > > Hiroshi > > > On Tue, Apr 13, 2010 at 11:21 AM, Hiroshi Yamauchi wrote: > >> Hi Jon, >> >> I finally got to this. Here's the webrev for a second version based on >> our discussion (thanks to Chuck Rasbold): >> >> http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >> >> The summary of change is that the logic for expansion based on >> MinHeapFreeRatio was added and only the flag for the System.gc was >> retained (and renamed to PSResizeByFreeRatioWithSystemGC.) >> >> Thanks, >> Hiroshi >> >> >> On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu wrote: >> >>> On 03/31/10 11:26, Hiroshi Yamauchi wrote: >>> >>>> ... >>>> >>>> I think we agree that it's a good idea to try to shrink the heap in >>>> response to System.gc() in such a scenario/app. >>>> >>> Yes on the shrinking on a System.gc() and perhaps for symmetry also >>> expanding >>> a small heap to MinFreeHeapRatio? UseAdaptiveSizePolicy will shrink the >>> heap >>> down during periods of low activity and it might be useful to swiftly expand >>> the >>> heap on a System.gc(). >>> >>>> Since we are talking about a setting where the free ratio flags takes >>>> precedence over the psAdaptiveSizePolicy's throughput goals, the suggested >>>> logic in the original webrev is perhaps not so terrible? If so, I suppose >>>> the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with that >>>> because it can shrink the heap regardless of the throughput goal. It may >>>> make sense to remove UseFreeRatioForParallelGC and keep >>>> UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it happen >>>> inside psAdaptiveSizePolicy instead, the current webrev does not work. >>>> >>>> >>> I like the structure of the original webrev with regard to the logic for >>> using FreeRation. It's simpler than embedding it in the >>> PSAdaptivesizePolicy. >>> >>> >>> 243 if (UseFreeRatioOnlyInSystemGCForParallelGC && >>> 245 gc_cause == GCCause::_java_lang_system_gc)) { >>> compute_new_size(); <<<<<<<< generalization of >>> <<<<<<<< try_to_shrink_by_free_ratio() >>> 248 } else { >>> use current UseAdaptiveSizePolicy >>> } >>> >>> >>> >>> >>> >>> From yamauchi at google.com Thu Apr 29 14:48:26 2010 From: yamauchi at google.com (Hiroshi Yamauchi) Date: Thu, 29 Apr 2010 14:48:26 -0700 Subject: Free ratio based heap shrinking in the parallel collector In-Reply-To: <4BD9F2E6.3090404@oracle.com> References: <4BA3AE88.3090002@sun.com> <56E32EB8-AA26-477B-872F-6AD5C2104900@Sun.COM> <4BB4C3A4.40701@oracle.com> <4BD9F2E6.3090404@oracle.com> Message-ID: OK. No problem. On Thu, Apr 29, 2010 at 1:58 PM, Jon Masamitsu wrote: > Hiroshi, > > These changes are what I was expecting after > we had talked. ?I still have to look at the details but may not > get to those for a couple of days. > > Jon > > On 04/28/10 13:37, Hiroshi Yamauchi wrote: >> >> Jon, >> >> Here's an update based on what we discussed: >> >> ?http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.02/ >> >> The summary of the latest changes is that >> >> 1. On minor collections, the free ratio is computed based on the young >> gen heap, rather than both the young gen and the old gen heaps. >> >> 2. When -XX:-UseAdaptiveSizePolicy, the free ratio based resizing >> happens on normal collections, rather than just on System.gc() when >> -XX:+PSResizeByFreeRatioWithSystemGC. >> >> Hiroshi >> >> >> On Tue, Apr 13, 2010 at 11:21 AM, Hiroshi Yamauchi >> wrote: >> >>> >>> Hi Jon, >>> >>> I finally got to this. Here's the webrev for a second version based on >>> our discussion (thanks to Chuck Rasbold): >>> >>> ?http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/ >>> >>> The summary of change is that the logic for expansion based on >>> MinHeapFreeRatio was added and only the flag for the System.gc was >>> retained (and renamed to PSResizeByFreeRatioWithSystemGC.) >>> >>> Thanks, >>> Hiroshi >>> >>> >>> On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu >>> wrote: >>> >>>> >>>> On 03/31/10 11:26, Hiroshi Yamauchi wrote: >>>> >>>>> >>>>> ... >>>>> >>>>> I think we agree that it's a good idea to try to shrink the heap in >>>>> response to System.gc() in such a scenario/app. >>>>> >>>> >>>> Yes on the shrinking on a System.gc() and perhaps for symmetry also >>>> expanding >>>> a small heap to MinFreeHeapRatio? ?UseAdaptiveSizePolicy will shrink the >>>> heap >>>> down during periods of low activity and it might be useful to swiftly >>>> expand >>>> the >>>> heap on a System.gc(). >>>> >>>>> >>>>> Since we are talking about a setting where the free ratio flags takes >>>>> precedence over the psAdaptiveSizePolicy's throughput goals, the >>>>> suggested >>>>> logic in the original webrev is perhaps not so terrible? If so, I >>>>> suppose >>>>> the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with >>>>> that >>>>> because it can shrink the heap regardless of the throughput goal. It >>>>> may >>>>> make sense to remove UseFreeRatioForParallelGC and keep >>>>> UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it >>>>> happen >>>>> inside psAdaptiveSizePolicy instead, the current webrev does not work. >>>>> >>>>> >>>> >>>> I like the structure of the original webrev with regard to the logic for >>>> using FreeRation. ?It's simpler than embedding it in the >>>> PSAdaptivesizePolicy. >>>> >>>> >>>> 243 ? ? if (UseFreeRatioOnlyInSystemGCForParallelGC && >>>> 245 ? ? ? ? ? gc_cause == GCCause::_java_lang_system_gc)) { >>>> ? ? ? ? compute_new_size(); ?<<<<<<<< ?generalization of >>>> ? ? ? ? ? ? <<<<<<<< ?try_to_shrink_by_free_ratio() >>>> 248 ? ? } else { >>>> ? ? ? ? use current UseAdaptiveSizePolicy >>>> ? ? ? } >>>> >>>> >>>> >>>> >>>> >>>> > > From john.coomes at oracle.com Thu Apr 29 21:31:17 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:31:17 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b90 for changeset 425ba3efabbf Message-ID: <20100430043117.8444F443E4@hg.openjdk.java.net> Changeset: 97d8b6c659c2 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/97d8b6c659c2 Added tag jdk7-b90 for changeset 425ba3efabbf ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:31:20 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:31:20 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b90 for changeset 56ce07b0eb47 Message-ID: <20100430043123.1C699443E5@hg.openjdk.java.net> Changeset: bcd2fc089227 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/bcd2fc089227 Added tag jdk7-b90 for changeset 56ce07b0eb47 ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:34:15 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:34:15 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b90 for changeset c5d932ee326d Message-ID: <20100430043415.A73A2443E7@hg.openjdk.java.net> Changeset: b89b2c3044a2 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/b89b2c3044a2 Added tag jdk7-b90 for changeset c5d932ee326d ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:34:18 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:34:18 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b90 for changeset ead7c4566a00 Message-ID: <20100430043418.96FE2443E8@hg.openjdk.java.net> Changeset: cf4686bf35ab Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/cf4686bf35ab Added tag jdk7-b90 for changeset ead7c4566a00 ! .hgtags From john.coomes at oracle.com Thu Apr 29 21:36:22 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:36:22 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 37 new changesets Message-ID: <20100430044433.C695D443E9@hg.openjdk.java.net> Changeset: 471c3c1f18d1 Author: bae Date: 2010-04-20 11:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/471c3c1f18d1 6936389: FontManager.fileCloser may cause memory leak in applets Reviewed-by: igor, prr, ant ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java + test/sun/awt/font/ClassLoaderLeakTest.java Changeset: bd5d1afc00ab Author: lana Date: 2010-04-20 16:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bd5d1afc00ab Merge Changeset: 43b8a8bc8208 Author: uta Date: 2010-04-14 15:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/43b8a8bc8208 6920842: Wheel events do not bubbling to the browser if they was not treated in applet. Reviewed-by: art, anthony, peterz ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java Changeset: ba8ecdbf0b88 Author: lana Date: 2010-04-15 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ba8ecdbf0b88 Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: f51dc9fc72d3 Author: lana Date: 2010-04-20 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f51dc9fc72d3 Merge Changeset: b48c141258e1 Author: peytoia Date: 2010-04-13 13:47 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b48c141258e1 6709938: RFE: Support more scripts in JDK logical fonts using new fonts in Windows XP and later. Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 98359a01cbe0 Author: okutsu Date: 2010-04-14 13:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/98359a01cbe0 6941948: NumaricShaper.shape() doesn't work with NumericShaper.Range.EASTERN_ARABIC Reviewed-by: peytoia ! src/share/classes/java/awt/font/NumericShaper.java + test/java/awt/font/NumericShaper/EasternArabicTest.java Changeset: 4d8b1b04544c Author: lana Date: 2010-04-15 11:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4d8b1b04544c Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java ! src/windows/classes/sun/awt/windows/fontconfig.properties - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: 17d17234a1d9 Author: okutsu Date: 2010-04-16 15:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/17d17234a1d9 6609675: [Fmt-Da] DateFormat.parse() on a timezone changes its calendar's timezone Reviewed-by: peytoia ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/SimpleDateFormat.java Changeset: f75f5e2274d5 Author: rupashka Date: 2010-04-16 13:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f75f5e2274d5 6922179: SynthTextPaneUI.installUI() doesn't set component to opaque as specified Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java Changeset: 584dcb7ecaf9 Author: naoto Date: 2010-04-19 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/584dcb7ecaf9 6943941: Rebranding issues with some tests in jdk/test/java/util Reviewed-by: ohair ! test/java/util/Locale/Bug4175998Test.java ! test/java/util/ResourceBundle/Bug4083270Test.java ! test/java/util/ResourceBundle/Bug4165815Test.java ! test/java/util/ResourceBundle/Bug4168625Class.java ! test/java/util/ResourceBundle/Bug4168625Getter.java ! test/java/util/ResourceBundle/Bug4168625Resource.java ! test/java/util/ResourceBundle/Bug4168625Resource2.java ! test/java/util/ResourceBundle/Bug4168625Resource2_en_US.java ! test/java/util/ResourceBundle/Bug4168625Resource3.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en_CA.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en_IE.java ! test/java/util/ResourceBundle/Bug4168625Resource3_en_US.java ! test/java/util/ResourceBundle/Bug4177489Test.java ! test/java/util/ResourceBundle/Bug4177489_Resource.java ! test/java/util/ResourceBundle/Bug4177489_Resource_jf.java Changeset: 2571720800a6 Author: peytoia Date: 2010-04-20 15:01 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2571720800a6 6945238: (tz) Support tzdata2010i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica Changeset: 0d9662f62d0d Author: lana Date: 2010-04-20 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0d9662f62d0d Merge Changeset: 710c4493902f Author: mullan Date: 2010-04-09 07:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/710c4493902f 6909281: 6u19 b99(pit):Error loading first applet in browser session( both FF && IE, windows ): NPE is thrown Summary: Fix for 6633872 causes NPE due to uninitialised ProtectionDomain class Reviewed-by: andrew ! src/share/classes/sun/misc/SharedSecrets.java Changeset: 89f4ec9e4b33 Author: xuelei Date: 2010-04-10 09:13 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/89f4ec9e4b33 6941936: Broken pipe error of test case DNSIdentities.java Reviewed-by: chegar ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java Changeset: 507cd94489e7 Author: sherman Date: 2010-04-12 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/507cd94489e7 6942707: nwe Big5.map for HKSCS2008 missed 5 codepoints Summary: updated the Big5.map table to add 5 entries Reviewed-by: okutsu - make/tools/CharsetMapping/Big5.c2b ! make/tools/CharsetMapping/Big5.map Changeset: 6b641c576e77 Author: valeriep Date: 2010-04-07 17:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6b641c576e77 6918573: sun.security.pkcs11.P11RSACipher.finalize() is a scalability blocker Summary: Removed the finalize() methods and use PhantomReference in Session to do auto clean up. Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/Session.java ! src/share/classes/sun/security/pkcs11/SessionManager.java Changeset: a45217204978 Author: valeriep Date: 2010-04-12 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a45217204978 Merge - make/tools/CharsetMapping/Big5.c2b Changeset: 1672f0212f02 Author: chegar Date: 2010-04-13 12:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1672f0212f02 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String Reviewed-by: alanb, michaelm, andrew ! src/share/classes/java/net/NetworkInterface.java Changeset: ed61accf772e Author: chegar Date: 2010-04-15 16:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ed61accf772e 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux Reviewed-by: andrew ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java Changeset: c70d4266d474 Author: sherman Date: 2010-04-15 17:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c70d4266d474 6931676: TEST_BUG: wrong value for bugid in comments Summary: update to the correct bugid Reviewed-by: martin ! test/java/util/regex/RegExTest.java Changeset: db4fd2fdf196 Author: weijun Date: 2010-04-16 10:06 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/db4fd2fdf196 6937978: let keytool -gencert generate the chain Reviewed-by: mullan ! src/share/classes/sun/security/tools/KeyTool.java ! test/sun/security/tools/keytool/selfissued.sh Changeset: 0d989dc383d3 Author: weijun Date: 2010-04-16 10:13 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0d989dc383d3 6939248: Jarsigner can't extract Extended Key Usage from Timestamp Reply correctly Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/TimestampedSigner.java + test/sun/security/tools/jarsigner/TimestampCheck.java + test/sun/security/tools/jarsigner/ts.sh Changeset: c444651077d2 Author: andrew Date: 2010-04-16 09:54 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c444651077d2 6944361: Missing CKR_ values in PKCS11Exception Summary: Allow native NSS errors to be observed and correctly reported Reviewed-by: wetmore, valeriep ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/x509/X509Key.java Changeset: 7ecc023957d8 Author: lana Date: 2010-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7ecc023957d8 Merge Changeset: 97fb6f6d230a Author: weijun Date: 2010-04-20 19:30 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/97fb6f6d230a 6944847: native gss lib names on linux Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java + test/sun/security/krb5/Krb5NameEquals.java + test/sun/security/krb5/runNameEquals.sh Changeset: d8ad2da3ecf3 Author: wetmore Date: 2010-04-20 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d8ad2da3ecf3 6945604: wrong error message in CardImpl.java Reviewed-by: mullan ! src/share/classes/sun/security/smartcardio/CardImpl.java Changeset: 884df20e9cce Author: lana Date: 2010-04-20 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/884df20e9cce Merge - make/tools/CharsetMapping/Big5.c2b Changeset: 9bf334e32d35 Author: yhuang Date: 2010-01-21 22:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9bf334e32d35 6916787: Ukrainian currency name needs to be fixed Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 00890dd53f45 Author: yhuang Date: 2010-01-27 23:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/00890dd53f45 6919624: minimalDaysInFirstWeek ressource for hungarian is wrong Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CalendarData_hu.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 0173ef08dcc8 Author: yhuang Date: 2010-02-11 20:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0173ef08dcc8 6776102: sun/util/resources/TimeZone/Bug6317929.java test failed against 6u12b01 and passed against 6u11b03 Reviewed-by: yhuang, peytoia ! test/sun/util/resources/TimeZone/Bug6317929.java Changeset: b2485d8eba40 Author: yhuang Date: 2010-04-11 21:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b2485d8eba40 Merge - make/java/redist/FILES.gmk - make/java/text/FILES_java.gmk - make/sun/nio/FILES_java.gmk - src/share/classes/sun/dyn/util/BytecodeSignature.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java Changeset: babd3f260d32 Author: yhuang Date: 2010-04-11 23:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/babd3f260d32 6875904: Java 7 message synchronization 1 Reviewed-by: ogino, faryad ! make/sun/launcher/Makefile ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties + src/share/classes/sun/launcher/resources/launcher_de.properties + src/share/classes/sun/launcher/resources/launcher_es.properties + src/share/classes/sun/launcher/resources/launcher_fr.properties + src/share/classes/sun/launcher/resources/launcher_it.properties + src/share/classes/sun/launcher/resources/launcher_ja.properties + src/share/classes/sun/launcher/resources/launcher_ko.properties + src/share/classes/sun/launcher/resources/launcher_sv.properties + src/share/classes/sun/launcher/resources/launcher_zh_CN.properties + src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: 7794a4a38e99 Author: yhuang Date: 2010-04-20 01:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7794a4a38e99 Merge - make/tools/src/build/tools/charsetmapping/CharsetMapping.java - make/tools/src/build/tools/charsetmapping/GenerateDBCS.java - make/tools/src/build/tools/charsetmapping/GenerateEUC_TW.java - make/tools/src/build/tools/charsetmapping/GenerateMapping.java - make/tools/src/build/tools/charsetmapping/GenerateSBCS.java - src/share/classes/sun/io/ByteToCharHKSCS.java - src/share/classes/sun/io/ByteToCharHKSCS_2001.java - src/share/classes/sun/io/CharToByteHKSCS.java - src/share/classes/sun/io/CharToByteHKSCS_2001.java - src/share/classes/sun/nio/cs/ext/Big5.java - src/share/classes/sun/nio/cs/ext/HKSCS_2001.java - test/java/net/Socket/FDClose.java - test/lib/security/cacerts/VerifyCACerts.java Changeset: b5ae88dd3dbd Author: mikejwre Date: 2010-04-28 20:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b5ae88dd3dbd Merge Changeset: ab117ded3e3f Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ab117ded3e3f Added tag jdk7-b90 for changeset 7f90d0b9dbb7 ! .hgtags Changeset: 08a31cab971f Author: mikejwre Date: 2010-04-29 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/08a31cab971f Merge - make/tools/CharsetMapping/Big5.c2b From john.coomes at oracle.com Thu Apr 29 21:53:25 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 04:53:25 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 9 new changesets Message-ID: <20100430045344.F37D8443F0@hg.openjdk.java.net> Changeset: 96072ad00783 Author: jjg Date: 2010-04-09 15:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/96072ad00783 6942649: add hidden option to identify location and version of javac classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javac/T6942649.java Changeset: 396b117c1743 Author: mcimadamore Date: 2010-04-14 12:23 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/396b117c1743 6939618: Revert 'simple' diamond implementation Summary: backout changeset for 6840638 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java - test/tools/javac/generics/diamond/neg/Neg01.java - test/tools/javac/generics/diamond/neg/Neg01.out - test/tools/javac/generics/diamond/neg/Neg02.java - test/tools/javac/generics/diamond/neg/Neg02.out - test/tools/javac/generics/diamond/neg/Neg03.java - test/tools/javac/generics/diamond/neg/Neg03.out - test/tools/javac/generics/diamond/neg/Neg04.java - test/tools/javac/generics/diamond/neg/Neg04.out - test/tools/javac/generics/diamond/neg/Neg05.java - test/tools/javac/generics/diamond/neg/Neg05.out - test/tools/javac/generics/diamond/pos/Pos01.java - test/tools/javac/generics/diamond/pos/Pos02.java - test/tools/javac/generics/diamond/pos/Pos03.java - test/tools/javac/generics/diamond/pos/Pos04.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/tools/javac/processing/model/element/TestAnonClassNames.java Changeset: 9d9d08922405 Author: mcimadamore Date: 2010-04-14 12:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/9d9d08922405 6939620: Switch to 'complex' diamond inference scheme Summary: Implement new inference scheme for diamond operator that takes into account type of actual arguments supplied to constructor Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/6840059/T6840059.out + test/tools/javac/generics/diamond/neg/Neg01.java + test/tools/javac/generics/diamond/neg/Neg01.out + test/tools/javac/generics/diamond/neg/Neg02.java + test/tools/javac/generics/diamond/neg/Neg02.out + test/tools/javac/generics/diamond/neg/Neg03.java + test/tools/javac/generics/diamond/neg/Neg03.out + test/tools/javac/generics/diamond/neg/Neg04.java + test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/generics/diamond/neg/Neg05.java + test/tools/javac/generics/diamond/neg/Neg05.out + test/tools/javac/generics/diamond/neg/Neg06.java + test/tools/javac/generics/diamond/neg/Neg06.out + test/tools/javac/generics/diamond/neg/Neg07.java + test/tools/javac/generics/diamond/neg/Neg07.out + test/tools/javac/generics/diamond/neg/Neg08.java + test/tools/javac/generics/diamond/neg/Neg08.out + test/tools/javac/generics/diamond/neg/Neg09.java + test/tools/javac/generics/diamond/neg/Neg09.out + test/tools/javac/generics/diamond/neg/Neg10.java + test/tools/javac/generics/diamond/neg/Neg10.out + test/tools/javac/generics/diamond/neg/Neg11.java + test/tools/javac/generics/diamond/neg/Neg11.out + test/tools/javac/generics/diamond/pos/Pos01.java + test/tools/javac/generics/diamond/pos/Pos02.java + test/tools/javac/generics/diamond/pos/Pos03.java + test/tools/javac/generics/diamond/pos/Pos04.java + test/tools/javac/generics/diamond/pos/Pos05.java Changeset: 37fa8cd046ab Author: lana Date: 2010-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/37fa8cd046ab Merge Changeset: 06e06ec0d6f2 Author: yhuang Date: 2010-04-11 23:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/06e06ec0d6f2 6875904: Java 7 message synchronization 1 Reviewed-by: ogino, faryad ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties Changeset: 053bf290d575 Author: yhuang Date: 2010-04-20 01:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/053bf290d575 Merge - test/tools/javap/T6305779.java Changeset: b68de5eee27b Author: mikejwre Date: 2010-04-28 20:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/b68de5eee27b Merge Changeset: ebf79cbf5711 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ebf79cbf5711 Added tag jdk7-b90 for changeset 71c2c23a7c35 ! .hgtags Changeset: 97b6fa97b8dd Author: mikejwre Date: 2010-04-29 14:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/97b6fa97b8dd Merge ! test/tools/javac/generics/diamond/neg/Neg01.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.java ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.java ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.java ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg05.java ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/pos/Pos01.java ! test/tools/javac/generics/diamond/pos/Pos02.java ! test/tools/javac/generics/diamond/pos/Pos03.java ! test/tools/javac/generics/diamond/pos/Pos04.java From john.coomes at oracle.com Fri Apr 30 02:12:00 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:12:00 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b91 for changeset 97d8b6c659c2 Message-ID: <20100430091200.25C084446D@hg.openjdk.java.net> Changeset: 5f5c33d417f3 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/5f5c33d417f3 Added tag jdk7-b91 for changeset 97d8b6c659c2 ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:12:02 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:12:02 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b91 for changeset bcd2fc089227 Message-ID: <20100430091204.A15964446E@hg.openjdk.java.net> Changeset: 930582f667a1 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/930582f667a1 Added tag jdk7-b91 for changeset bcd2fc089227 ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:15:32 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:15:32 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b91 for changeset b89b2c3044a2 Message-ID: <20100430091532.DF1D344472@hg.openjdk.java.net> Changeset: e6a40e4bb104 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/e6a40e4bb104 Added tag jdk7-b91 for changeset b89b2c3044a2 ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:15:36 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:15:36 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b91 for changeset cf4686bf35ab Message-ID: <20100430091536.B2ECE44473@hg.openjdk.java.net> Changeset: df7c033f6a11 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/df7c033f6a11 Added tag jdk7-b91 for changeset cf4686bf35ab ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:15:42 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:15:42 +0000 Subject: hg: jdk7/hotspot-gc/jdk: Added tag jdk7-b91 for changeset 08a31cab971f Message-ID: <20100430091602.9E4E744474@hg.openjdk.java.net> Changeset: f2dce7210cc0 Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f2dce7210cc0 Added tag jdk7-b91 for changeset 08a31cab971f ! .hgtags From john.coomes at oracle.com Fri Apr 30 02:18:14 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Apr 2010 09:18:14 +0000 Subject: hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b91 for changeset 97b6fa97b8dd Message-ID: <20100430091817.DD28E44475@hg.openjdk.java.net> Changeset: 98cba5876cb5 Author: mikejwre Date: 2010-04-29 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/98cba5876cb5 Added tag jdk7-b91 for changeset 97b6fa97b8dd ! .hgtags