From John.Coomes at oracle.com Thu Feb 2 13:29:35 2012 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 2 Feb 2012 13:29:35 -0800 Subject: review request (XS) - 6679764 enable par compact by default Message-ID: <20267.63.709501.703384@oracle.com> I'd appreciate reviews of this small change to enable parallel compaction (-XX:+UseParallelOldGC) by default when UseParallelGC is enabled. http://cr.openjdk.java.net/~jcoomes/6679764-pc-default/ -John From john.coomes at oracle.com Thu Feb 2 18:17:25 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 02:17:25 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 6679764: enable parallel compaction by default Message-ID: <20120203021729.E58DE47323@hg.openjdk.java.net> Changeset: 24cae3e4cbaa Author: jcoomes Date: 2012-02-02 16:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/24cae3e4cbaa 6679764: enable parallel compaction by default Reviewed-by: phh, jmasa ! src/share/vm/runtime/arguments.cpp From john.coomes at oracle.com Thu Feb 2 20:53:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:53:07 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b24 for changeset 1a5f1d6b98d6 Message-ID: <20120203045307.69A3847339@hg.openjdk.java.net> Changeset: 5350cd6e0cc0 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/5350cd6e0cc0 Added tag jdk8-b24 for changeset 1a5f1d6b98d6 ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:53:13 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:53:13 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b24 for changeset b98f0e6dddf9 Message-ID: <20120203045316.28F4E4733A@hg.openjdk.java.net> Changeset: e45d6b406d5f Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/e45d6b406d5f Added tag jdk8-b24 for changeset b98f0e6dddf9 ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:53:24 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:53:24 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b24 for changeset 7836655e2495 Message-ID: <20120203045324.63F884733B@hg.openjdk.java.net> Changeset: bb694c151fc7 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/bb694c151fc7 Added tag jdk8-b24 for changeset 7836655e2495 ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:53:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:53:32 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b24 for changeset e0d90803439b Message-ID: <20120203045332.39B104733C@hg.openjdk.java.net> Changeset: b376d901e006 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b376d901e006 Added tag jdk8-b24 for changeset e0d90803439b ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:53:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:53:40 +0000 Subject: hg: hsx/hotspot-gc/jdk: Added tag jdk8-b24 for changeset 34029a0c69bb Message-ID: <20120203045420.6EB3E4733D@hg.openjdk.java.net> Changeset: 8da468cf037b Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8da468cf037b Added tag jdk8-b24 for changeset 34029a0c69bb ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:55:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:55:39 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b24 for changeset 6c9d21ca92c4 Message-ID: <20120203045546.77FC94733E@hg.openjdk.java.net> Changeset: 5a784dab75f1 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/5a784dab75f1 Added tag jdk8-b24 for changeset 6c9d21ca92c4 ! .hgtags From ysr1729 at gmail.com Thu Feb 2 22:21:10 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 2 Feb 2012 22:21:10 -0800 Subject: review request (XS) - 6679764 enable par compact by default In-Reply-To: <20267.63.709501.703384@oracle.com> References: <20267.63.709501.703384@oracle.com> Message-ID: Hi John, Thanks for fixing this; about time :-) -- ramki On Thu, Feb 2, 2012 at 1:29 PM, John Coomes wrote: > I'd appreciate reviews of this small change to enable parallel > compaction (-XX:+UseParallelOldGC) by default when UseParallelGC is > enabled. > > http://cr.openjdk.java.net/~jcoomes/6679764-pc-default/ > > -John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120202/2cb6d664/attachment.html From john.coomes at oracle.com Sat Feb 4 04:21:01 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 04 Feb 2012 12:21:01 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 36 new changesets Message-ID: <20120204122218.A38044736F@hg.openjdk.java.net> Changeset: af739d5ab23c Author: bpittore Date: 2012-01-21 23:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/af739d5ab23c 6972759: Step over not working after thrown exception and Pop Summary: reset jvmtithreadstate exception state after frame pop and forceearlyreturn processed Reviewed-by: minqi, dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: 583b428aa858 Author: coleenp Date: 2012-01-23 17:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/583b428aa858 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: d6660fedbab5 Author: phh Date: 2012-01-24 14:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d6660fedbab5 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Summary: Modify jprt.properties to run OSX builds and tests. Reviewed-by: dcubed, kamg, ohair, dholmes Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: bf864f701a4a Author: dsamersoff Date: 2012-01-25 02:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf864f701a4a 7066129: GarbageCollectorMXBean#getLastGcInfo leaks native memory Summary: Make GCStatInfo a resource object Reviewed-by: phh, coleenp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp Changeset: df88f58f3b61 Author: dsamersoff Date: 2012-01-24 20:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/df88f58f3b61 Merge Changeset: e8a4934564b2 Author: phh Date: 2012-01-24 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e8a4934564b2 7125793: MAC: test_gamma should always work Summary: Fix gamma launcher on Mac OS X and reconcile test_gamma script on Unix platforms Reviewed-by: dcubed, ohair, jcoomes, dholmes, ksrini Contributed-by: james.melvin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/posix/launcher/java_md.c Changeset: 78dadb7b16ab Author: phh Date: 2012-01-25 01:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/78dadb7b16ab Merge Changeset: d708a8cdd022 Author: kamg Date: 2012-01-25 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d708a8cdd022 Merge Changeset: 520830f632e7 Author: fparain Date: 2012-01-25 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/520830f632e7 7131346: Parsing of boolean arguments to diagnostic commands is broken Reviewed-by: dholmes, dcubed ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 24ec1a6d6ef3 Author: fparain Date: 2012-01-25 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/24ec1a6d6ef3 Merge Changeset: a42c07c38c47 Author: dsamersoff Date: 2012-01-25 21:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a42c07c38c47 7132515: Add dcmd to manage UnlockingCommercialFeature flag Summary: Added dcmd to unlock or check status of UnlockingCommercialFeature flag Reviewed-by: fparain, rottenha ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 6d00795f99a1 Author: dsamersoff Date: 2012-01-25 15:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6d00795f99a1 Merge Changeset: 6db63e782d3d Author: dsamersoff Date: 2012-01-25 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6db63e782d3d Merge Changeset: de268c8a8075 Author: phh Date: 2012-01-26 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/de268c8a8075 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Summary: Add CriticalPriority == MaxPriority+1 and enable scheduling class as well as thread priority to change on Solaris. Reviewed-by: dholmes, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: bf5da1648543 Author: kamg Date: 2012-01-27 10:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf5da1648543 Merge ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp Changeset: 6edfe6e42a68 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6edfe6e42a68 Added tag jdk8-b23 for changeset e850d8e7ea54 ! .hgtags Changeset: 9e177d44b10f Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9e177d44b10f Merge Changeset: a80fd4f45d7a Author: amurillo Date: 2012-01-27 14:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a80fd4f45d7a Added tag hs23-b12 for changeset 9e177d44b10f ! .hgtags Changeset: 9f1c2b7cdfb6 Author: amurillo Date: 2012-01-27 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9f1c2b7cdfb6 7135385: new hotspot build - hs23-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d96c130c9399 Merge Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 481a9443f721 Author: phh Date: 2012-02-01 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/481a9443f721 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Summary: Add support for packaging HotSpot JVM builds in universal binaries Reviewed-by: dholmes, kamg, dcubed, phh Contributed-by: james.melvin at oracle.com ! make/Makefile ! make/bsd/makefiles/defs.make + make/bsd/makefiles/universal.gmk ! make/defs.make Changeset: 527cf36f4a20 Author: fparain Date: 2012-02-03 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/527cf36f4a20 Merge ! src/share/vm/runtime/globals.hpp Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f067b4e0e04b Author: roland Date: 2012-02-01 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f067b4e0e04b 7090976: Eclipse/CDT causes a JVM crash while indexing C++ code Summary: too optimistic inlining decision confuses local value numbering. Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.cpp + test/compiler/7090976/Test7090976.java Changeset: aa3d708d67c4 Author: never Date: 2012-02-01 07:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aa3d708d67c4 7141200: log some interesting information in ring buffers for crashes Reviewed-by: kvn, jrose, kevinw, brutisso, twisti, jmasa ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! 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_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0382d2b469b2 Author: never Date: 2012-02-01 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0382d2b469b2 7013347: allow crypto functions to be called inline to enhance performance Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 392a3f07d567 Author: twisti Date: 2012-02-02 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/392a3f07d567 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 Reviewed-by: twisti Contributed-by: Volker Simonis ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/7141637/SpreadNullArg.java Changeset: 379b22e03c32 Author: jcoomes Date: 2012-02-03 12:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/379b22e03c32 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ab44ceb4d57 Author: jcoomes Date: 2012-02-03 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5ab44ceb4d57 Merge From ysr1729 at gmail.com Mon Feb 6 11:01:33 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 6 Feb 2012 11:01:33 -0800 Subject: separate ParallelGCThreads ? Message-ID: Hi all -- I am wondering if there may be any traction to using a different "ParallelGCThreads" setting for old and young phases of Parallel GC, somewhat analogous (although i understand the analogy is too loose) to how there are separate numbers of (max) parallel threads for concurrent and stop-world phases of CMS and G1. It's of course almost trivial to implement as of now, but it introduces yet more (user-settable) options, multiplying existing confusion of the roles of many of these options. In some sense, Jon's recent infrastructure work on eventually enabling the jvm/gc to dynamically flex the # of GC threads works in that direction in a more pleasant and ergonomic fashion, but I was wondering whether, in the interim, we can have a stop-gap where the users can explicitly set the values for (for example) old and new collections via different parameters. I am myself somewhat conflicted by this suggestion since it starts us down a somewhat slippery slope of that leads to an explosion of options, but at the same time, I'd like to hear any thoughts, comments or opinions on this suggestion. thanks! -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120206/472f0cba/attachment.html From john.coomes at oracle.com Mon Feb 6 22:09:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 07 Feb 2012 06:09:04 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 8 new changesets Message-ID: <20120207060926.1FEA9473B5@hg.openjdk.java.net> Changeset: 905945c5913e Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/905945c5913e Added tag jdk8-b24 for changeset a80fd4f45d7a ! .hgtags Changeset: b22de8247499 Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b22de8247499 Merge Changeset: 4e9b30938cbf Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4e9b30938cbf Added tag hs23-b13 for changeset b22de8247499 ! .hgtags Changeset: 1f22b536808b Author: amurillo Date: 2012-02-03 18:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1f22b536808b 7142393: new hotspot build - hs23-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 585feefad374 Author: phh Date: 2012-02-06 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/585feefad374 7142852: MAC: Comment out JPRT jbb tests on Mac OS X until 7142850 is resolved Summary: Comment out JPRT jbb tests on Mac OS X until GUI hang can be fixed Reviewed-by: dholmes, brutisso, phh Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: 64b46f975ab8 Author: phh Date: 2012-02-06 14:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/64b46f975ab8 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Summary: Fix EXPORT_PATH overrides on Mac OS X and only change default. Reviewed-by: phh, dcubed Contributed-by: james.melvin at oracle.com ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/universal.gmk Changeset: 9ad8feb5afbd Author: amurillo Date: 2012-02-06 12:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9ad8feb5afbd Added tag hs23-b14 for changeset 64b46f975ab8 ! .hgtags Changeset: 3c4621be5149 Author: amurillo Date: 2012-02-06 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c4621be5149 7143122: new hotspot build - hs23-b15 Reviewed-by: jcoomes ! make/hotspot_version From bengt.rutisson at oracle.com Tue Feb 7 02:03:33 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 07 Feb 2012 11:03:33 +0100 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F21AF07.4090401@oracle.com> References: <4F21AF07.4090401@oracle.com> Message-ID: <4F30F6F5.3070709@oracle.com> Hi Tony, Overall this looks good. Did you do any testing to see that it behaves as you expect now? Some style related comments: You mentioned that you can be persuaded to remove the switch that always returns true from retry_unsuccessful_concurrent_full_gc(). I'm in favor of removing that. Actually I think that if we do that we could inline the the remaining part of retry_unsuccessful_concurrent_full_gc() inside the collect() method. That would make it more readable to me. The name "retry_unsuccessful_concurrent_full_gc" is complicated enough that I would have to go and look what it does anyway. Since it will only be one line if it is inlined I would prefer that. Finally a coding standard question regarding switch statements. The hotspot code in general is not consistent in this case, and neither is the GC code or even the G1 code. But should the "case" statements be indented one level under the "switch" statement? To me that makes sense since the switch statement starts a new code block. I assume you have a different opinion since you wrote it differently, but what is the rational behind it? To exemplify. This: switch (cause) { case GCCause::_gc_locker: return GCLockerInvokesConcurrent; case GCCause::_java_lang_system_gc: return ExplicitGCInvokesConcurrent; case GCCause::_g1_humongous_allocation: return true; default: return false; } would be easier for me to read if it was: switch (cause) { case GCCause::_gc_locker: return GCLockerInvokesConcurrent; case GCCause::_java_lang_system_gc: return ExplicitGCInvokesConcurrent; case GCCause::_g1_humongous_allocation: return true; default: return false; } Anyway, just ,minor stuff. So, in general: ship it! Bengt On 2012-01-26 20:52, Tony Printezis wrote: > Hi all, > > Can I please have a couple of code reviews for the following change? > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ > > The issue is that a GC attempt that's supposed to explicitly start a > concurrent marking cycle might be unsuccessful (as another GC might > get scheduled first) which will prevent the cycle from starting. The > idea is to retry such unsuccessful attempts. > > I also changed should_do_concurrent_full_gc() from an if-statement to > a switch statement. I discussed it with Bengt (the last person to > modify that method) and we both think that the switch statement is > more readable. > > BTW, I did a couple of iterations of this fix to address the slightly > different approach Bengt took in the cycle initiation after hum > allocation code (i.e., start the cycle before the allocation, not > after). In the end the current version of > retry_unsuccessful_concurrent_full_gc(), a new method I added, always > returns true for all causes. I'm inclined to leave the switch in, even > just for the comments per cause. I could be persuaded to replace it > with return true; statement though. > > Tony > From ysr1729 at gmail.com Tue Feb 7 09:04:52 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 7 Feb 2012 09:04:52 -0800 Subject: UseAdaptiveGCBoundary? Message-ID: Hi Jon, John, et al. -- What's the current status of and experience with UseAdaptiveGCBoundary? As I recall a (long) while ago there was some performance issue with it, although I can't recall the specific details. Is this flag something you recommend trying out? Are there performance sharp-corners that one should watch out for if one were to enable this feature ? thanks for any tips! -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120207/49c77e5d/attachment.html From tony.printezis at oracle.com Tue Feb 7 09:38:08 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 07 Feb 2012 12:38:08 -0500 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F30F6F5.3070709@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> Message-ID: <4F316180.10103@oracle.com> Bengt, Thanks for looking at it, inline. On 02/07/2012 05:03 AM, Bengt Rutisson wrote: > > Hi Tony, > > Overall this looks good. > > Did you do any testing to see that it behaves as you expect now? I wrote a test that exposes the issue (when +ExplicitGCInvokesConcurrent is used) and I attached it to the CR (it initiates marking cycles constantly, I just compare the number of System.gc()'s to the number of actual marking cycles in the log). I did the first implementation based on the first version of your "hum alloc can start a conc cycle" fix and I had to update it based on the changes you pushed afterwards. I just reran the test to make sure all's still well, and it is: vanilla: tried to initiate 2610 cycles, 2595 cycles actually initiated with fix: tried to initiate 2613 cycles, 2613 cycles actually initiated > Some style related comments: > > You mentioned that you can be persuaded to remove the switch that > always returns true from retry_unsuccessful_concurrent_full_gc(). I'm > in favor of removing that. Actually I think that if we do that we > could inline the the remaining part of > retry_unsuccessful_concurrent_full_gc() inside the collect() method. > That would make it more readable to me. Actually, we don't need to inline anything. The change becomes this (ignore the 0 lines changed in the .hpp file, this is a side-effect of having two MQ patches stacked): http://cr.openjdk.java.net/~tonyp/7129892/webrev.2/ (note that only when the GC cause is appropriate and any related arguments are set appropriately we try to initiate a conc cycle, so we don't need to recheck) FWIW, I like the version with the method even if it's just for the extra comments which might be helpful to whoever reads the code in the future. > The name "retry_unsuccessful_concurrent_full_gc" is complicated enough > that I would have to go and look what it does anyway. Since it will > only be one line if it is inlined I would prefer that. You can propose an alternative. :-) I couldn't come up with one... > Finally a coding standard question regarding switch statements. The > hotspot code in general is not consistent in this case, and neither is > the GC code or even the G1 code. But should the "case" statements be > indented one level under the "switch" statement? To me that makes > sense since the switch statement starts a new code block. I assume you > have a different opinion since you wrote it differently, but what is > the rational behind it? > > To exemplify. This: > > switch (cause) { > case GCCause::_gc_locker: return > GCLockerInvokesConcurrent; > case GCCause::_java_lang_system_gc: return > ExplicitGCInvokesConcurrent; > case GCCause::_g1_humongous_allocation: return true; > default: return false; > } > > would be easier for me to read if it was: > > switch (cause) { > case GCCause::_gc_locker: return > GCLockerInvokesConcurrent; > case GCCause::_java_lang_system_gc: return > ExplicitGCInvokesConcurrent; > case GCCause::_g1_humongous_allocation: return true; > default: return false; > } I'm OK either way and I do think the latter is a bit nicer. But by default emacs does not indent so I went with it. I'll add the indentation. > Anyway, just ,minor stuff. So, in general: ship it! Thanks! Tony > Bengt > > On 2012-01-26 20:52, Tony Printezis wrote: >> Hi all, >> >> Can I please have a couple of code reviews for the following change? >> >> http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ >> >> The issue is that a GC attempt that's supposed to explicitly start a >> concurrent marking cycle might be unsuccessful (as another GC might >> get scheduled first) which will prevent the cycle from starting. The >> idea is to retry such unsuccessful attempts. >> >> I also changed should_do_concurrent_full_gc() from an if-statement to >> a switch statement. I discussed it with Bengt (the last person to >> modify that method) and we both think that the switch statement is >> more readable. >> >> BTW, I did a couple of iterations of this fix to address the slightly >> different approach Bengt took in the cycle initiation after hum >> allocation code (i.e., start the cycle before the allocation, not >> after). In the end the current version of >> retry_unsuccessful_concurrent_full_gc(), a new method I added, always >> returns true for all causes. I'm inclined to leave the switch in, >> even just for the comments per cause. I could be persuaded to replace >> it with return true; statement though. >> >> Tony >> > From john.cuthbertson at oracle.com Tue Feb 7 10:24:42 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 07 Feb 2012 10:24:42 -0800 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F21AF07.4090401@oracle.com> References: <4F21AF07.4090401@oracle.com> Message-ID: <4F316C6A.4060002@oracle.com> Hi Tony, I forgot that you had this out for review. Anyway - this looks good to me. JohnC On 01/26/12 11:52, Tony Printezis wrote: > Hi all, > > Can I please have a couple of code reviews for the following change? > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ > > The issue is that a GC attempt that's supposed to explicitly start a > concurrent marking cycle might be unsuccessful (as another GC might > get scheduled first) which will prevent the cycle from starting. The > idea is to retry such unsuccessful attempts. > > I also changed should_do_concurrent_full_gc() from an if-statement to > a switch statement. I discussed it with Bengt (the last person to > modify that method) and we both think that the switch statement is > more readable. > > BTW, I did a couple of iterations of this fix to address the slightly > different approach Bengt took in the cycle initiation after hum > allocation code (i.e., start the cycle before the allocation, not > after). In the end the current version of > retry_unsuccessful_concurrent_full_gc(), a new method I added, always > returns true for all causes. I'm inclined to leave the switch in, even > just for the comments per cause. I could be persuaded to replace it > with return true; statement though. > > Tony > From tony.printezis at oracle.com Tue Feb 7 10:38:02 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 07 Feb 2012 13:38:02 -0500 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F316180.10103@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> <4F316180.10103@oracle.com> Message-ID: <4F316F8A.8060606@oracle.com> On 02/07/2012 12:38 PM, Tony Printezis wrote: > > Actually, we don't need to inline anything. The change becomes this > (ignore the 0 lines changed in the .hpp file, this is a side-effect of > having two MQ patches stacked): > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.2/ > > (note that only when the GC cause is appropriate and any related > arguments are set appropriately we try to initiate a conc cycle, so we > don't need to recheck) Scratch the above, I forgot that the method was also checking whether a Full GC was done or not (and I think we should still test for that) and the above version ignores that. FWIW, John prefers to leave the new method in, even just for the documentation aspect (and I agree). Can you think of a better name? Tony From bengt.rutisson at oracle.com Wed Feb 8 03:50:05 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 08 Feb 2012 12:50:05 +0100 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F316180.10103@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> <4F316180.10103@oracle.com> Message-ID: <4F32616D.5040201@oracle.com> Tony, On 2012-02-07 18:38, Tony Printezis wrote: > Bengt, > > Thanks for looking at it, inline. > > On 02/07/2012 05:03 AM, Bengt Rutisson wrote: >> >> Hi Tony, >> >> Overall this looks good. >> >> Did you do any testing to see that it behaves as you expect now? > > I wrote a test that exposes the issue (when > +ExplicitGCInvokesConcurrent is used) and I attached it to the CR (it > initiates marking cycles constantly, I just compare the number of > System.gc()'s to the number of actual marking cycles in the log). I > did the first implementation based on the first version of your "hum > alloc can start a conc cycle" fix and I had to update it based on the > changes you pushed afterwards. I just reran the test to make sure > all's still well, and it is: > > vanilla: tried to initiate 2610 cycles, 2595 cycles actually initiated > > with fix: tried to initiate 2613 cycles, 2613 cycles actually initiated Excellent! Thanks. Sorry for not checking the CR properly before asking. >> Some style related comments: >> >> You mentioned that you can be persuaded to remove the switch that >> always returns true from retry_unsuccessful_concurrent_full_gc(). I'm >> in favor of removing that. Actually I think that if we do that we >> could inline the the remaining part of >> retry_unsuccessful_concurrent_full_gc() inside the collect() method. >> That would make it more readable to me. > > Actually, we don't need to inline anything. The change becomes this > (ignore the 0 lines changed in the .hpp file, this is a side-effect of > having two MQ patches stacked): > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.2/ > > (note that only when the GC cause is appropriate and any related > arguments are set appropriately we try to initiate a conc cycle, so we > don't need to recheck) As you noted in your next email we still need one check. > FWIW, I like the version with the method even if it's just for the > extra comments which might be helpful to whoever reads the code in the > future. Well, we don't really need the switch to have comments, do we? Also, I would prefer to have the comments in should_do_concurrent_full_gc(). That's where I would look for the information that the comments provide. Infact, that method already has a comment in the hpp file: // It decides whether an explicit GC should start a concurrent cycle // instead of doing a STW GC. Currently, a concurrent cycle is // explicitly started if: // (a) cause == _gc_locker and +GCLockerInvokesConcurrent, or // (b) cause == _java_lang_system_gc and +ExplicitGCInvokesConcurrent. // (c) cause == _g1_humongous_allocation bool should_do_concurrent_full_gc(GCCause::Cause cause); Mabye just make this comment more detailed? >> The name "retry_unsuccessful_concurrent_full_gc" is complicated >> enough that I would have to go and look what it does anyway. Since it >> will only be one line if it is inlined I would prefer that. > > You can propose an alternative. :-) I couldn't come up with one... I still think we should just inline it and not have the method. >> Finally a coding standard question regarding switch statements. The >> hotspot code in general is not consistent in this case, and neither >> is the GC code or even the G1 code. But should the "case" statements >> be indented one level under the "switch" statement? To me that makes >> sense since the switch statement starts a new code block. I assume >> you have a different opinion since you wrote it differently, but what >> is the rational behind it? >> >> To exemplify. This: >> >> switch (cause) { >> case GCCause::_gc_locker: return >> GCLockerInvokesConcurrent; >> case GCCause::_java_lang_system_gc: return >> ExplicitGCInvokesConcurrent; >> case GCCause::_g1_humongous_allocation: return true; >> default: return false; >> } >> >> would be easier for me to read if it was: >> >> switch (cause) { >> case GCCause::_gc_locker: return >> GCLockerInvokesConcurrent; >> case GCCause::_java_lang_system_gc: return >> ExplicitGCInvokesConcurrent; >> case GCCause::_g1_humongous_allocation: return true; >> default: return false; >> } > > I'm OK either way and I do think the latter is a bit nicer. But by > default emacs does not indent so I went with it. I'll add the > indentation. Great! :-) Bengt >> Anyway, just ,minor stuff. So, in general: ship it! > > Thanks! > > Tony > >> Bengt >> >> On 2012-01-26 20:52, Tony Printezis wrote: >>> Hi all, >>> >>> Can I please have a couple of code reviews for the following change? >>> >>> http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ >>> >>> The issue is that a GC attempt that's supposed to explicitly start a >>> concurrent marking cycle might be unsuccessful (as another GC might >>> get scheduled first) which will prevent the cycle from starting. The >>> idea is to retry such unsuccessful attempts. >>> >>> I also changed should_do_concurrent_full_gc() from an if-statement >>> to a switch statement. I discussed it with Bengt (the last person to >>> modify that method) and we both think that the switch statement is >>> more readable. >>> >>> BTW, I did a couple of iterations of this fix to address the >>> slightly different approach Bengt took in the cycle initiation after >>> hum allocation code (i.e., start the cycle before the allocation, >>> not after). In the end the current version of >>> retry_unsuccessful_concurrent_full_gc(), a new method I added, >>> always returns true for all causes. I'm inclined to leave the switch >>> in, even just for the comments per cause. I could be persuaded to >>> replace it with return true; statement though. >>> >>> Tony >>> >> From tony.printezis at oracle.com Wed Feb 8 06:47:18 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 08 Feb 2012 09:47:18 -0500 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F32616D.5040201@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> <4F316180.10103@oracle.com> <4F32616D.5040201@oracle.com> Message-ID: <4F328AF6.301@oracle.com> Bengt, Inline. On 02/08/2012 06:50 AM, Bengt Rutisson wrote: > >> I wrote a test that exposes the issue (when >> +ExplicitGCInvokesConcurrent is used) and I attached it to the CR (it >> initiates marking cycles constantly, I just compare the number of >> System.gc()'s to the number of actual marking cycles in the log). I >> did the first implementation based on the first version of your "hum >> alloc can start a conc cycle" fix and I had to update it based on the >> changes you pushed afterwards. I just reran the test to make sure >> all's still well, and it is: >> >> vanilla: tried to initiate 2610 cycles, 2595 cycles actually initiated >> >> with fix: tried to initiate 2613 cycles, 2613 cycles actually initiated > > Excellent! Thanks. Sorry for not checking the CR properly before asking. Np (I should have mentioned the test in the code review request). I couldn't come up with a straightforward way to also test the fix when cycles are initiated by humongous allocations. But, given that that code path also calls collect() I think exercising the code with +ExplicitGCInvokesConcurrent should be enough. >> FWIW, I like the version with the method even if it's just for the >> extra comments which might be helpful to whoever reads the code in >> the future. > > Well, we don't really need the switch to have comments, do we? Also, I > would prefer to have the comments in should_do_concurrent_full_gc(). > That's where I would look for the information that the comments provide. > > Infact, that method already has a comment in the hpp file: > > // It decides whether an explicit GC should start a concurrent cycle > // instead of doing a STW GC. Currently, a concurrent cycle is > // explicitly started if: > // (a) cause == _gc_locker and +GCLockerInvokesConcurrent, or > // (b) cause == _java_lang_system_gc and +ExplicitGCInvokesConcurrent. > // (c) cause == _g1_humongous_allocation > bool should_do_concurrent_full_gc(GCCause::Cause cause); > > Mabye just make this comment more detailed? Do you like this version better? http://cr.openjdk.java.net/~tonyp/7129892/webrev.3/ I also noticed that we were calling SharedHeap::heap()->total_collections() from a few places in G1CollectedHeap and we can call total_collections() directly given that G1CH extends SharedHeap. I simplified those. Tony >>> Finally a coding standard question regarding switch statements. The >>> hotspot code in general is not consistent in this case, and neither >>> is the GC code or even the G1 code. But should the "case" statements >>> be indented one level under the "switch" statement? To me that makes >>> sense since the switch statement starts a new code block. I assume >>> you have a different opinion since you wrote it differently, but >>> what is the rational behind it? >>> >>> To exemplify. This: >>> >>> switch (cause) { >>> case GCCause::_gc_locker: return >>> GCLockerInvokesConcurrent; >>> case GCCause::_java_lang_system_gc: return >>> ExplicitGCInvokesConcurrent; >>> case GCCause::_g1_humongous_allocation: return true; >>> default: return false; >>> } >>> >>> would be easier for me to read if it was: >>> >>> switch (cause) { >>> case GCCause::_gc_locker: return >>> GCLockerInvokesConcurrent; >>> case GCCause::_java_lang_system_gc: return >>> ExplicitGCInvokesConcurrent; >>> case GCCause::_g1_humongous_allocation: return true; >>> default: return false; >>> } >> >> I'm OK either way and I do think the latter is a bit nicer. But by >> default emacs does not indent so I went with it. I'll add the >> indentation. > > Great! :-) > > Bengt > >>> Anyway, just ,minor stuff. So, in general: ship it! >> >> Thanks! >> >> Tony >> >>> Bengt >>> >>> On 2012-01-26 20:52, Tony Printezis wrote: >>>> Hi all, >>>> >>>> Can I please have a couple of code reviews for the following change? >>>> >>>> http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ >>>> >>>> The issue is that a GC attempt that's supposed to explicitly start >>>> a concurrent marking cycle might be unsuccessful (as another GC >>>> might get scheduled first) which will prevent the cycle from >>>> starting. The idea is to retry such unsuccessful attempts. >>>> >>>> I also changed should_do_concurrent_full_gc() from an if-statement >>>> to a switch statement. I discussed it with Bengt (the last person >>>> to modify that method) and we both think that the switch statement >>>> is more readable. >>>> >>>> BTW, I did a couple of iterations of this fix to address the >>>> slightly different approach Bengt took in the cycle initiation >>>> after hum allocation code (i.e., start the cycle before the >>>> allocation, not after). In the end the current version of >>>> retry_unsuccessful_concurrent_full_gc(), a new method I added, >>>> always returns true for all causes. I'm inclined to leave the >>>> switch in, even just for the comments per cause. I could be >>>> persuaded to replace it with return true; statement though. >>>> >>>> Tony >>>> >>> > From ysr1729 at gmail.com Wed Feb 8 11:13:25 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 8 Feb 2012 11:13:25 -0800 Subject: separate ParallelGCThreads ? In-Reply-To: References: Message-ID: Hmm... I suppose the lack of reaction must mean that there is no traction for Yet Another JVM Option ;-) Although it is arguable (theoretically at least) that the optimal level of parallelism for two different GC algorithms may not necessarily be identical. I wonder if the performance folks have noticed any negative scaling of parallel old at parallelism levels that would be otherwise optimal for parallel scavenge. Charlie or John? (I'll go see if Charlie's book says anything about that :-) -- ramki On Mon, Feb 6, 2012 at 11:01 AM, Srinivas Ramakrishna wrote: > > Hi all -- > > I am wondering if there may be any traction to using a different > "ParallelGCThreads" setting for old and young > phases of Parallel GC, somewhat analogous (although i understand the > analogy is too loose) to how there are separate > numbers of (max) parallel threads for concurrent and stop-world phases of > CMS and G1. It's of course > almost trivial to implement as of now, but it introduces yet more > (user-settable) options, multiplying existing > confusion of the roles of many of these options. > > In some sense, Jon's recent infrastructure work on eventually enabling the > jvm/gc to dynamically flex the # of GC threads > works in that direction in a more pleasant and ergonomic fashion, but I > was wondering whether, in the interim, we can have > a stop-gap where the users can explicitly set the values for (for example) > old and new collections via different parameters. I am > myself somewhat conflicted by this suggestion since it starts us down a > somewhat slippery slope of > that leads to an explosion of options, but at the same time, I'd like to > hear any thoughts, comments or > opinions on this suggestion. > > thanks! > -- ramki > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120208/f5d3bfbf/attachment.html From bengt.rutisson at oracle.com Thu Feb 9 01:05:17 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 09 Feb 2012 10:05:17 +0100 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F328AF6.301@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> <4F316180.10103@oracle.com> <4F32616D.5040201@oracle.com> <4F328AF6.301@oracle.com> Message-ID: <4F338C4D.20500@oracle.com> Tony, The new webrev looks good! Ship it! Good idea to clean up the calls to SharedHeap::heap()->total_collections(). There are a couple of more places in g1CollectedHeap.cpp where we unnecessarily use the SharedHeap:: prefix. Don't know if you want to change them as well, of if you think they are good for readability. Below is a small patch to remove those usages as well. I'll leave it up to you to decide on using it or not. I'm fine with the latest webrev as it is. Thanks, Bengt diff --git a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp @@ -3171,12 +3171,12 @@ // We apply the relevant closures to all the oops in the // system dictionary, the string table and the code cache. - const int so = SharedHeap::SO_AllClasses | SharedHeap::SO_Strings | SharedHeap::SO_CodeCache; + const int so = SO_AllClasses | SO_Strings | SO_CodeCache; process_strong_roots(true, // activate StrongRootsScope true, // we set "collecting perm gen" to true, // so we don't reset the dirty cards in the perm gen. - SharedHeap::ScanningOption(so), // roots scanning options + ScanningOption(so), // roots scanning options &rootsCl, &blobsCl, &rootsCl); @@ -4756,7 +4756,7 @@ void G1CollectedHeap:: g1_process_strong_roots(bool collecting_perm_gen, - SharedHeap::ScanningOption so, + ScanningOption so, OopClosure* scan_non_heap_roots, OopsInHeapRegionClosure* scan_rs, OopsInGenClosure* scan_perm, @@ -4828,7 +4828,7 @@ G1CollectedHeap::g1_process_weak_roots(OopClosure* root_closure, OopClosure* non_root_closure) { CodeBlobToOopClosure roots_in_blobs(root_closure, /*do_marking=*/ false); - SharedHeap::process_weak_roots(root_closure, &roots_in_blobs, non_root_closure); + process_weak_roots(root_closure, &roots_in_blobs, non_root_closure); } // Weak Reference Processing support On 2012-02-08 15:47, Tony Printezis wrote: > Bengt, > > Inline. > > On 02/08/2012 06:50 AM, Bengt Rutisson wrote: >> >>> I wrote a test that exposes the issue (when >>> +ExplicitGCInvokesConcurrent is used) and I attached it to the CR >>> (it initiates marking cycles constantly, I just compare the number >>> of System.gc()'s to the number of actual marking cycles in the log). >>> I did the first implementation based on the first version of your >>> "hum alloc can start a conc cycle" fix and I had to update it based >>> on the changes you pushed afterwards. I just reran the test to make >>> sure all's still well, and it is: >>> >>> vanilla: tried to initiate 2610 cycles, 2595 cycles actually initiated >>> >>> with fix: tried to initiate 2613 cycles, 2613 cycles actually initiated >> >> Excellent! Thanks. Sorry for not checking the CR properly before asking. > > Np (I should have mentioned the test in the code review request). I > couldn't come up with a straightforward way to also test the fix when > cycles are initiated by humongous allocations. But, given that that > code path also calls collect() I think exercising the code with > +ExplicitGCInvokesConcurrent should be enough. > >>> FWIW, I like the version with the method even if it's just for the >>> extra comments which might be helpful to whoever reads the code in >>> the future. >> >> Well, we don't really need the switch to have comments, do we? Also, >> I would prefer to have the comments in >> should_do_concurrent_full_gc(). That's where I would look for the >> information that the comments provide. >> >> Infact, that method already has a comment in the hpp file: >> >> // It decides whether an explicit GC should start a concurrent cycle >> // instead of doing a STW GC. Currently, a concurrent cycle is >> // explicitly started if: >> // (a) cause == _gc_locker and +GCLockerInvokesConcurrent, or >> // (b) cause == _java_lang_system_gc and +ExplicitGCInvokesConcurrent. >> // (c) cause == _g1_humongous_allocation >> bool should_do_concurrent_full_gc(GCCause::Cause cause); >> >> Mabye just make this comment more detailed? > > Do you like this version better? > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.3/ > > I also noticed that we were calling > SharedHeap::heap()->total_collections() from a few places in > G1CollectedHeap and we can call total_collections() directly given > that G1CH extends SharedHeap. I simplified those. > > Tony > >>>> Finally a coding standard question regarding switch statements. The >>>> hotspot code in general is not consistent in this case, and neither >>>> is the GC code or even the G1 code. But should the "case" >>>> statements be indented one level under the "switch" statement? To >>>> me that makes sense since the switch statement starts a new code >>>> block. I assume you have a different opinion since you wrote it >>>> differently, but what is the rational behind it? >>>> >>>> To exemplify. This: >>>> >>>> switch (cause) { >>>> case GCCause::_gc_locker: return >>>> GCLockerInvokesConcurrent; >>>> case GCCause::_java_lang_system_gc: return >>>> ExplicitGCInvokesConcurrent; >>>> case GCCause::_g1_humongous_allocation: return true; >>>> default: return false; >>>> } >>>> >>>> would be easier for me to read if it was: >>>> >>>> switch (cause) { >>>> case GCCause::_gc_locker: return >>>> GCLockerInvokesConcurrent; >>>> case GCCause::_java_lang_system_gc: return >>>> ExplicitGCInvokesConcurrent; >>>> case GCCause::_g1_humongous_allocation: return true; >>>> default: return false; >>>> } >>> >>> I'm OK either way and I do think the latter is a bit nicer. But by >>> default emacs does not indent so I went with it. I'll add the >>> indentation. >> >> Great! :-) >> >> Bengt >> >>>> Anyway, just ,minor stuff. So, in general: ship it! >>> >>> Thanks! >>> >>> Tony >>> >>>> Bengt >>>> >>>> On 2012-01-26 20:52, Tony Printezis wrote: >>>>> Hi all, >>>>> >>>>> Can I please have a couple of code reviews for the following change? >>>>> >>>>> http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ >>>>> >>>>> The issue is that a GC attempt that's supposed to explicitly start >>>>> a concurrent marking cycle might be unsuccessful (as another GC >>>>> might get scheduled first) which will prevent the cycle from >>>>> starting. The idea is to retry such unsuccessful attempts. >>>>> >>>>> I also changed should_do_concurrent_full_gc() from an if-statement >>>>> to a switch statement. I discussed it with Bengt (the last person >>>>> to modify that method) and we both think that the switch statement >>>>> is more readable. >>>>> >>>>> BTW, I did a couple of iterations of this fix to address the >>>>> slightly different approach Bengt took in the cycle initiation >>>>> after hum allocation code (i.e., start the cycle before the >>>>> allocation, not after). In the end the current version of >>>>> retry_unsuccessful_concurrent_full_gc(), a new method I added, >>>>> always returns true for all causes. I'm inclined to leave the >>>>> switch in, even just for the comments per cause. I could be >>>>> persuaded to replace it with return true; statement though. >>>>> >>>>> Tony >>>>> >>>> >> From jon.masamitsu at oracle.com Thu Feb 9 06:39:22 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 09 Feb 2012 06:39:22 -0800 Subject: UseAdaptiveGCBoundary? In-Reply-To: References: Message-ID: <4F33DA9A.7020605@oracle.com> Ramki, I cannot say that I would recommend it's use. The problem with UseAdaptiveGCBoundary is all in the policy that it uses to decide how to move the boundary. It used to sometimes back itself into a corner (young gen size and old gen size which was sub optimal) and not be able to get itself out. I think that can still be a problem but perhaps the bigger problem is that the policy thinks that it is optimal to divide the the GC times evenly between the young GC's and old GC's and that is not always the case. In general that policy produces reasonably good results but when that policy can drive the moving of the boundary, I've seen cases where there are performance regressions (i.e., GC ergonomics turned on but worse performance when the boundary moving is additionally turned on). Jon On 2/7/2012 9:04 AM, Srinivas Ramakrishna wrote: > Hi Jon, John, et al. -- > > What's the current status of and experience with UseAdaptiveGCBoundary? > As I recall a (long) while ago there was some performance issue with it, > although > I can't recall the specific details. > Is this flag something you recommend trying out? Are there performance > sharp-corners that one should watch out for if one were to enable this > feature ? > > thanks for any tips! > -- ramki > From ysr1729 at gmail.com Thu Feb 9 08:47:32 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 9 Feb 2012 08:47:32 -0800 Subject: UseAdaptiveGCBoundary? In-Reply-To: <4F33DA9A.7020605@oracle.com> References: <4F33DA9A.7020605@oracle.com> Message-ID: Thanks Jon for the informative response! -- ramki On Thu, Feb 9, 2012 at 6:39 AM, Jon Masamitsu wrote: > Ramki, > > I cannot say that I would recommend it's use. The problem with > UseAdaptiveGCBoundary > is all in the policy that it uses to decide how to move the boundary. It > used to sometimes > back itself into a corner (young gen size and old gen size which was sub > optimal) > and not be able to get itself out. I think that can still be a problem > but perhaps the > bigger problem is that the policy thinks that it is optimal to divide the > the GC times > evenly between the young GC's and old GC's and that is not always the > case. In > general that policy produces reasonably good results but when that policy > can > drive the moving of the boundary, I've seen cases where there are > performance > regressions (i.e., GC ergonomics turned on but worse performance when the > boundary moving is additionally turned on). > > Jon > > > On 2/7/2012 9:04 AM, Srinivas Ramakrishna wrote: > >> Hi Jon, John, et al. -- >> >> What's the current status of and experience with UseAdaptiveGCBoundary? >> As I recall a (long) while ago there was some performance issue with it, >> although >> I can't recall the specific details. >> Is this flag something you recommend trying out? Are there performance >> sharp-corners that one should watch out for if one were to enable this >> feature ? >> >> thanks for any tips! >> -- ramki >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120209/1d869d2f/attachment.html From ysr1729 at gmail.com Thu Feb 9 08:52:49 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 9 Feb 2012 08:52:49 -0800 Subject: separate ParallelGCThreads ? In-Reply-To: <4F332FD9.7040000@oracle.com> References: <4F332FD9.7040000@oracle.com> Message-ID: On Wed, Feb 8, 2012 at 6:30 PM, charlie hunt wrote: > Hi Ramki, > > Given that we (ideally) don't see ParallelOld GCs very frequently, we > haven't really had a catalyst to push us to looking into having different > settings for parallel scavenge versus parallel compaction threads. In > short, I think most folks are happy compaction is multi-threaded with > parallel GC (i.e. shorter in duration). ;-) > > yes, i totally understand :-) > However, that doesn't mean that there may be some negative scaling of > parallel old where it would otherwise be optimal for parallel scavenge. > > Have you seen something that suggests we should consider looking at this a > bit more closely? Or, was it Jon's changes that got you thinking about the > possibility ? > I think that may be the case.... although the evidence is still fragmentary and anecdotal, and i haven't seen (or collected) real scaling data yet. Will let you know once data is clearer. thanks Charlie! -- ramki > > thanks, > > charlie ... > > On 02/ 8/12 11:13 AM, Srinivas Ramakrishna wrote: > > Hmm... I suppose the lack of reaction must mean that there is no traction > for Yet Another JVM Option ;-) > Although it is arguable (theoretically at least) that the optimal level of > parallelism for two different GC algorithms > may not necessarily be identical. I wonder if the performance folks have > noticed any negative > scaling of parallel old at parallelism levels that would be otherwise > optimal for parallel scavenge. Charlie or John? > (I'll go see if Charlie's book says anything about that :-) > > -- ramki > > On Mon, Feb 6, 2012 at 11:01 AM, Srinivas Ramakrishna wrote: > >> >> Hi all -- >> >> I am wondering if there may be any traction to using a different >> "ParallelGCThreads" setting for old and young >> phases of Parallel GC, somewhat analogous (although i understand the >> analogy is too loose) to how there are separate >> numbers of (max) parallel threads for concurrent and stop-world phases >> of CMS and G1. It's of course >> almost trivial to implement as of now, but it introduces yet more >> (user-settable) options, multiplying existing >> confusion of the roles of many of these options. >> >> In some sense, Jon's recent infrastructure work on eventually enabling >> the jvm/gc to dynamically flex the # of GC threads >> works in that direction in a more pleasant and ergonomic fashion, but I >> was wondering whether, in the interim, we can have >> a stop-gap where the users can explicitly set the values for (for >> example) old and new collections via different parameters. I am >> myself somewhat conflicted by this suggestion since it starts us down a >> somewhat slippery slope of >> that leads to an explosion of options, but at the same time, I'd like to >> hear any thoughts, comments or >> opinions on this suggestion. >> >> thanks! >> -- ramki >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120209/71455e10/attachment.html From charlie.hunt at oracle.com Wed Feb 8 18:30:49 2012 From: charlie.hunt at oracle.com (charlie hunt) Date: Wed, 08 Feb 2012 18:30:49 -0800 Subject: separate ParallelGCThreads ? In-Reply-To: References: Message-ID: <4F332FD9.7040000@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120208/74d1e86e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3757 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120208/74d1e86e/smime-0001.p7s From tony.printezis at oracle.com Thu Feb 9 11:16:52 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 09 Feb 2012 14:16:52 -0500 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F338C4D.20500@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> <4F316180.10103@oracle.com> <4F32616D.5040201@oracle.com> <4F328AF6.301@oracle.com> <4F338C4D.20500@oracle.com> Message-ID: <4F341BA4.9060305@oracle.com> Bengt, Inline. On 02/09/2012 04:05 AM, Bengt Rutisson wrote: > > Tony, > > The new webrev looks good! Ship it! Thanks. :-) > Good idea to clean up the calls to > SharedHeap::heap()->total_collections(). > > There are a couple of more places in g1CollectedHeap.cpp where we > unnecessarily use the SharedHeap:: prefix. Don't know if you want to > change them as well, of if you think they are good for readability. > Below is a small patch to remove those usages as well. I'll leave it > up to you to decide on using it or not. I'm fine with the latest > webrev as it is. I adopted your changes to drop the SharedHeap:: prefix for ScanningOption and friends (and there was an extra instance of that in the .hpp file). I think I'll leave SharedHeap::process_weak_roots(root_closure, &roots_in_blobs, non_root_closure); as is if that's OK. G1 also has a process_weak_roots() method and, even though it has a different parameter list, I think the ShredHeap:: here makes the code a bit more readable (IMHO). It will also guard against future "surprises" if we change the parameter list of either process_weak_roots(). Latest full webrev here: http://cr.openjdk.java.net/~tonyp/7129892/webrev.4/webrev.all/ And these are just the above changes: http://cr.openjdk.java.net/~tonyp/7129892/webrev.4/webrev.1.G1Latest/ Tony > Thanks, > Bengt > > diff --git a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > @@ -3171,12 +3171,12 @@ > > // We apply the relevant closures to all the oops in the > // system dictionary, the string table and the code cache. > - const int so = SharedHeap::SO_AllClasses | SharedHeap::SO_Strings > | SharedHeap::SO_CodeCache; > + const int so = SO_AllClasses | SO_Strings | SO_CodeCache; > > process_strong_roots(true, // activate StrongRootsScope > true, // we set "collecting perm gen" > to true, > // so we don't reset the dirty > cards in the perm gen. > - SharedHeap::ScanningOption(so), // roots > scanning options > + ScanningOption(so), // roots scanning options > &rootsCl, > &blobsCl, > &rootsCl); > @@ -4756,7 +4756,7 @@ > void > G1CollectedHeap:: > g1_process_strong_roots(bool collecting_perm_gen, > - SharedHeap::ScanningOption so, > + ScanningOption so, > OopClosure* scan_non_heap_roots, > OopsInHeapRegionClosure* scan_rs, > OopsInGenClosure* scan_perm, > @@ -4828,7 +4828,7 @@ > G1CollectedHeap::g1_process_weak_roots(OopClosure* root_closure, > OopClosure* non_root_closure) { > CodeBlobToOopClosure roots_in_blobs(root_closure, /*do_marking=*/ > false); > - SharedHeap::process_weak_roots(root_closure, &roots_in_blobs, > non_root_closure); > + process_weak_roots(root_closure, &roots_in_blobs, non_root_closure); > } > > // Weak Reference Processing support > > On 2012-02-08 15:47, Tony Printezis wrote: >> Bengt, >> >> Inline. >> >> On 02/08/2012 06:50 AM, Bengt Rutisson wrote: >>> >>>> I wrote a test that exposes the issue (when >>>> +ExplicitGCInvokesConcurrent is used) and I attached it to the CR >>>> (it initiates marking cycles constantly, I just compare the number >>>> of System.gc()'s to the number of actual marking cycles in the >>>> log). I did the first implementation based on the first version of >>>> your "hum alloc can start a conc cycle" fix and I had to update it >>>> based on the changes you pushed afterwards. I just reran the test >>>> to make sure all's still well, and it is: >>>> >>>> vanilla: tried to initiate 2610 cycles, 2595 cycles actually initiated >>>> >>>> with fix: tried to initiate 2613 cycles, 2613 cycles actually >>>> initiated >>> >>> Excellent! Thanks. Sorry for not checking the CR properly before >>> asking. >> >> Np (I should have mentioned the test in the code review request). I >> couldn't come up with a straightforward way to also test the fix when >> cycles are initiated by humongous allocations. But, given that that >> code path also calls collect() I think exercising the code with >> +ExplicitGCInvokesConcurrent should be enough. >> >>>> FWIW, I like the version with the method even if it's just for the >>>> extra comments which might be helpful to whoever reads the code in >>>> the future. >>> >>> Well, we don't really need the switch to have comments, do we? Also, >>> I would prefer to have the comments in >>> should_do_concurrent_full_gc(). That's where I would look for the >>> information that the comments provide. >>> >>> Infact, that method already has a comment in the hpp file: >>> >>> // It decides whether an explicit GC should start a concurrent cycle >>> // instead of doing a STW GC. Currently, a concurrent cycle is >>> // explicitly started if: >>> // (a) cause == _gc_locker and +GCLockerInvokesConcurrent, or >>> // (b) cause == _java_lang_system_gc and >>> +ExplicitGCInvokesConcurrent. >>> // (c) cause == _g1_humongous_allocation >>> bool should_do_concurrent_full_gc(GCCause::Cause cause); >>> >>> Mabye just make this comment more detailed? >> >> Do you like this version better? >> >> http://cr.openjdk.java.net/~tonyp/7129892/webrev.3/ >> >> I also noticed that we were calling >> SharedHeap::heap()->total_collections() from a few places in >> G1CollectedHeap and we can call total_collections() directly given >> that G1CH extends SharedHeap. I simplified those. >> >> Tony >> >>>>> Finally a coding standard question regarding switch statements. >>>>> The hotspot code in general is not consistent in this case, and >>>>> neither is the GC code or even the G1 code. But should the "case" >>>>> statements be indented one level under the "switch" statement? To >>>>> me that makes sense since the switch statement starts a new code >>>>> block. I assume you have a different opinion since you wrote it >>>>> differently, but what is the rational behind it? >>>>> >>>>> To exemplify. This: >>>>> >>>>> switch (cause) { >>>>> case GCCause::_gc_locker: return >>>>> GCLockerInvokesConcurrent; >>>>> case GCCause::_java_lang_system_gc: return >>>>> ExplicitGCInvokesConcurrent; >>>>> case GCCause::_g1_humongous_allocation: return true; >>>>> default: return false; >>>>> } >>>>> >>>>> would be easier for me to read if it was: >>>>> >>>>> switch (cause) { >>>>> case GCCause::_gc_locker: return >>>>> GCLockerInvokesConcurrent; >>>>> case GCCause::_java_lang_system_gc: return >>>>> ExplicitGCInvokesConcurrent; >>>>> case GCCause::_g1_humongous_allocation: return true; >>>>> default: return false; >>>>> } >>>> >>>> I'm OK either way and I do think the latter is a bit nicer. But by >>>> default emacs does not indent so I went with it. I'll add the >>>> indentation. >>> >>> Great! :-) >>> >>> Bengt >>> >>>>> Anyway, just ,minor stuff. So, in general: ship it! >>>> >>>> Thanks! >>>> >>>> Tony >>>> >>>>> Bengt >>>>> >>>>> On 2012-01-26 20:52, Tony Printezis wrote: >>>>>> Hi all, >>>>>> >>>>>> Can I please have a couple of code reviews for the following change? >>>>>> >>>>>> http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ >>>>>> >>>>>> The issue is that a GC attempt that's supposed to explicitly >>>>>> start a concurrent marking cycle might be unsuccessful (as >>>>>> another GC might get scheduled first) which will prevent the >>>>>> cycle from starting. The idea is to retry such unsuccessful >>>>>> attempts. >>>>>> >>>>>> I also changed should_do_concurrent_full_gc() from an >>>>>> if-statement to a switch statement. I discussed it with Bengt >>>>>> (the last person to modify that method) and we both think that >>>>>> the switch statement is more readable. >>>>>> >>>>>> BTW, I did a couple of iterations of this fix to address the >>>>>> slightly different approach Bengt took in the cycle initiation >>>>>> after hum allocation code (i.e., start the cycle before the >>>>>> allocation, not after). In the end the current version of >>>>>> retry_unsuccessful_concurrent_full_gc(), a new method I added, >>>>>> always returns true for all causes. I'm inclined to leave the >>>>>> switch in, even just for the comments per cause. I could be >>>>>> persuaded to replace it with return true; statement though. >>>>>> >>>>>> Tony >>>>>> >>>>> >>> > From john.coomes at oracle.com Thu Feb 9 20:54:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:54:11 +0000 Subject: hg: hsx/hotspot-gc: 4 new changesets Message-ID: <20120210045411.851A847438@hg.openjdk.java.net> Changeset: 0f653ee93477 Author: alanb Date: 2012-01-24 09:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/0f653ee93477 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties Changeset: bd3fcc98c5d2 Author: lana Date: 2012-01-28 20:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/bd3fcc98c5d2 Merge Changeset: 221a378e06a3 Author: lana Date: 2012-02-07 10:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/221a378e06a3 Merge Changeset: 2accafff224a Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/2accafff224a Added tag jdk8-b25 for changeset 221a378e06a3 ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:54:21 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:54:21 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b25 for changeset e45d6b406d5f Message-ID: <20120210045424.7F36F47439@hg.openjdk.java.net> Changeset: 79f709a099f4 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/79f709a099f4 Added tag jdk8-b25 for changeset e45d6b406d5f ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:54:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:54:32 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b25 for changeset bb694c151fc7 Message-ID: <20120210045432.23AC84743A@hg.openjdk.java.net> Changeset: dbb7283c197b Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/dbb7283c197b Added tag jdk8-b25 for changeset bb694c151fc7 ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:54:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:54:39 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b25 for changeset b376d901e006 Message-ID: <20120210045439.B0DD84743B@hg.openjdk.java.net> Changeset: 3518639eab6c Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/3518639eab6c Added tag jdk8-b25 for changeset b376d901e006 ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:55:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:55:53 +0000 Subject: hg: hsx/hotspot-gc/jdk: 47 new changesets Message-ID: <20120210051417.63EA947442@hg.openjdk.java.net> Changeset: ad9f1c8970da Author: prr Date: 2012-01-19 12:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ad9f1c8970da 7131153: GetDC called way too many times - causes bad performance. Reviewed-by: igor, jgodinez ! src/windows/native/sun/font/fontpath.c Changeset: f7dda4bbf1f9 Author: lana Date: 2012-01-28 22:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f7dda4bbf1f9 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 84b153cd9bd4 Author: denis Date: 2012-01-19 14:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/84b153cd9bd4 7121761: creation of java.awt.DataFlavour fails for turkish locale Reviewed-by: anthony ! src/share/classes/java/awt/datatransfer/MimeType.java Changeset: e32db6535c05 Author: alexsch Date: 2012-01-23 13:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e32db6535c05 7112854: [macosx] closed/javax/swing/JPopupMenu/Test6827786.java unstable on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: cc88a9c0474f Author: alexsch Date: 2012-01-23 13:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cc88a9c0474f 7116634: [macosx] closed/javax/swing/JTree/6263446/bug6263446Tree.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/6263446/bug6263446.java Changeset: 19431d07bc19 Author: denis Date: 2012-01-23 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/19431d07bc19 7130140: using horizontal scroll button on mouse causes a message to be printed on stdout Reviewed-by: art ! src/share/classes/java/awt/event/MouseEvent.java Changeset: 5255fd5b0418 Author: denis Date: 2012-01-24 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5255fd5b0418 7078460: JDialog is shown as separate icon on the taskbar Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: b4589ff4457c Author: malenkov Date: 2012-01-24 19:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b4589ff4457c 7121905: grammatically incorrect apostrophe in BeanInfo javadoc Reviewed-by: rupashka ! src/share/classes/java/beans/BeanInfo.java Changeset: 4f2a2bf0ce84 Author: rupashka Date: 2012-01-26 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4f2a2bf0ce84 7010561: Tab text position with Synth based LaF is different to Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7010561/bug7010561.java Changeset: cc9ff174a1c3 Author: alexsch Date: 2012-01-27 16:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cc9ff174a1c3 7122173: [macosx] Several Regression tests fail on MacOS Reviewed-by: rupashka + test/javax/swing/SwingUtilities/4917669/bug4917669.java + test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java + test/javax/swing/text/html/CSS/4530474/bug4530474.java + test/javax/swing/text/html/CSS/4530474/test.css + test/javax/swing/text/html/CSS/4530474/test.html Changeset: 96b5999af66b Author: alexsch Date: 2012-01-27 17:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/96b5999af66b 7109962: [macosx] closed/javax/swing/JList/6462008/bug6462008.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JList/6462008/bug6462008.java Changeset: 6a7109f52966 Author: alexsch Date: 2012-01-27 17:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6a7109f52966 7105040: [macosx] closed/javax/swing/JPopupMenu/4966112/bug4966112.java deadlocks on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/4966112/bug4966112.java Changeset: bc1c20ac8676 Author: chegar Date: 2012-01-27 13:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bc1c20ac8676 7110002: Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt Reviewed-by: art, prr, dholmes, alanb ! make/common/Release-embedded.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/jawt/Makefile ! make/sun/xawt/Makefile ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 5dab2d55bc5b Author: lana Date: 2012-01-28 22:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5dab2d55bc5b Merge - test/java/io/File/BlockIsDirectory.java Changeset: 39b661c5867a Author: alexsch Date: 2012-01-30 12:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/39b661c5867a 7122149: [macosx] closed/javax/swing/UITest/UITest.java fails on MacOS Reviewed-by: rupashka ! src/share/classes/sun/awt/OSInfo.java + test/javax/swing/UITest/UITest.java Changeset: 7d6c7dd72e25 Author: malenkov Date: 2012-01-31 14:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7d6c7dd72e25 7122138: IAE thrown because Introspector ignores synthetic methods Reviewed-by: rupashka ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/7122138/Test7122138.java + test/java/beans/Introspector/7122138/pack/Sub.java + test/java/beans/Introspector/7122138/pack/Super.java Changeset: c5c78f293ff8 Author: rupashka Date: 2012-01-31 17:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c5c78f293ff8 7082443: JComboBox not backward compatible (with Java 6) Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java + test/javax/swing/JComboBox/7082443/bug7082443.java Changeset: 363086137375 Author: lana Date: 2012-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/363086137375 Merge Changeset: 313da5d059bf Author: valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: 71200c517524 Author: darcy Date: 2012-01-20 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/71200c517524 4504839: Java libraries should provide support for unsigned integer arithmetic 4215269: Some Integer.toHexString(int) results cannot be decoded back to an int 6322074: Converting integers to string as if unsigned Reviewed-by: mduigou, emcmanus, flar ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Integer/Unsigned.java + test/java/lang/Long/Unsigned.java Changeset: d383b5d128e3 Author: xuelei Date: 2012-01-23 04:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d383b5d128e3 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 3df0bd3ed880 Author: mullan Date: 2012-01-23 12:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3df0bd3ed880 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 5e1ad6ad41b7 Author: mullan Date: 2012-01-23 13:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5e1ad6ad41b7 Merge Changeset: 914711cccc60 Author: darcy Date: 2012-01-23 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/914711cccc60 7132338: Use @code friendly idiom for '\' in javadoc Reviewed-by: alanb ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/StreamTokenizer.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/Properties.java Changeset: 237319a01a9a Author: alanb Date: 2012-01-24 09:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/237319a01a9a 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties ! test/ProblemList.txt Changeset: 718bca4e685f Author: rbackman Date: 2012-01-17 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/718bca4e685f 7132386: makefile support for tracing/Java Flight Recorder framework phase I Reviewed-by: ohair, dholmes, rottenha Contributed-by: Markus Gronlund , Erik Gahlin , Nils Loodin , Rickard Backman , Staffan Larsen ! make/com/oracle/Makefile + make/com/oracle/jfr/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: f64ea40293db Author: ksrini Date: 2012-01-24 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f64ea40293db 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Reviewed-by: alanb, chegar ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 303b67074666 Author: lancea Date: 2012-01-24 15:13 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/303b67074666 7132879: address Findbugs issue in WebRowSetXmlWriter Reviewed-by: forax ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Changeset: ceab7e149581 Author: peytoia Date: 2012-01-26 17:06 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ceab7e149581 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug7017458.java Changeset: 350971f50949 Author: rbackman Date: 2012-01-26 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/350971f50949 7133124: Remove redundant packages from JAR command line Reviewed-by: acorn, alanb, dholmes, rottenha ! make/common/Release.gmk Changeset: b518b160607f Author: lancea Date: 2012-01-26 19:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b518b160607f 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Reviewed-by: forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 5ee30ab905db Author: wetmore Date: 2012-01-26 17:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5ee30ab905db 7126889: Incorrect SSLEngine debug output Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/EngineArgs.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh Changeset: 7aa5ddfa3c9d Author: okutsu Date: 2012-01-27 14:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7aa5ddfa3c9d 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7130335.java Changeset: ff24779c147f Author: valeriep Date: 2012-01-27 15:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ff24779c147f 7136538: typo in test/Makefile under the jdk_security3 target Summary: Fixed the typo of "secrity". Reviewed-by: wetmore ! test/Makefile Changeset: 7dbc129d8e5c Author: ksrini Date: 2012-01-28 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7dbc129d8e5c 7127906: (launcher) convert the launcher regression tests to java Reviewed-by: darcy, naoto ! test/tools/launcher/Arrrghs.java + test/tools/launcher/ChangeDataModel.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/I18NJarTest.java + test/tools/launcher/I18NTest.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/Settings.java - test/tools/launcher/SomeException.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java - test/tools/launcher/UnicodeCleanup.java ! test/tools/launcher/UnicodeTest.java - test/tools/launcher/UnicodeTest.sh ! test/tools/launcher/UnresolvedExceptions.java - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 7a25b72b3644 Author: lana Date: 2012-01-28 20:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7a25b72b3644 Merge Changeset: f9fb8c4b4550 Author: dl Date: 2012-01-30 11:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f9fb8c4b4550 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/FutureTask.java + test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java + test/java/util/concurrent/FutureTask/ExplicitSet.java Changeset: 863a20b0bf08 Author: ngmr Date: 2012-01-10 00:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/863a20b0bf08 7123229: (coll) EnumMap.containsValue(null) returns true Summary: java.util.EnumMap.NULL equals() must only be true for itself Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/UniqueNullValue.java Changeset: 13978750cb87 Author: ngmr Date: 2012-01-31 10:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/13978750cb87 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 431bc327f34a Author: sla Date: 2012-01-31 10:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/431bc327f34a 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms Summary: Make sure HotSpot and JDK looks for well-known files in the same location Reviewed-by: dholmes, dsamersoff ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! test/ProblemList.txt Changeset: 663a6333105d Author: sla Date: 2012-01-31 04:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/663a6333105d Merge Changeset: 533bc0a10233 Author: lana Date: 2012-01-31 19:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/533bc0a10233 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: ce62fb7aa1b8 Author: lana Date: 2012-02-07 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ce62fb7aa1b8 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 1a99dad28223 Author: yhuang Date: 2012-02-06 18:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1a99dad28223 7129382: change minor unit of VND to 0 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/tablea1.txt Changeset: 930756e55285 Author: yhuang Date: 2012-02-06 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/930756e55285 Merge Changeset: ec17fbe5b8fb Author: katleman Date: 2012-02-08 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ec17fbe5b8fb Merge Changeset: 5aca406e87cb Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5aca406e87cb Added tag jdk8-b25 for changeset ec17fbe5b8fb ! .hgtags From john.coomes at oracle.com Thu Feb 9 21:51:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:51:06 +0000 Subject: hg: hsx/hotspot-gc/langtools: 7 new changesets Message-ID: <20120210055126.8FCD247449@hg.openjdk.java.net> Changeset: 51fb17abfc32 Author: mcimadamore Date: 2012-01-24 17:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/51fb17abfc32 7129801: Merge the two method applicability routines Summary: Resolve.java and Infer.java should reuse the same method applicability check routine Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java Changeset: ac36176b7de0 Author: jjh Date: 2012-01-24 15:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ac36176b7de0 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java Changeset: d16b464e742c Author: jjh Date: 2012-01-24 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d16b464e742c 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref Changeset: 332dfa0f91df Author: jjh Date: 2012-01-25 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/332dfa0f91df 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Reviewed-by: jjg ! test/tools/javac/7129225/AnnoProcessor.java ! test/tools/javac/7129225/NegTest.ref ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref Changeset: 7d412606d641 Author: lana Date: 2012-01-28 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/7d412606d641 Merge Changeset: 520c30f85bb5 Author: lana Date: 2012-02-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/520c30f85bb5 Merge Changeset: b556aa8a99c3 Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b556aa8a99c3 Added tag jdk8-b25 for changeset 520c30f85bb5 ! .hgtags From bengt.rutisson at oracle.com Fri Feb 10 00:06:11 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 10 Feb 2012 09:06:11 +0100 Subject: CRR (S): 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle In-Reply-To: <4F341BA4.9060305@oracle.com> References: <4F21AF07.4090401@oracle.com> <4F30F6F5.3070709@oracle.com> <4F316180.10103@oracle.com> <4F32616D.5040201@oracle.com> <4F328AF6.301@oracle.com> <4F338C4D.20500@oracle.com> <4F341BA4.9060305@oracle.com> Message-ID: <4F34CFF3.4010704@oracle.com> Tony, New webrev looks great! Thanks for updating it again. Bengt On 2012-02-09 20:16, Tony Printezis wrote: > Bengt, > > Inline. > > On 02/09/2012 04:05 AM, Bengt Rutisson wrote: >> >> Tony, >> >> The new webrev looks good! Ship it! > > Thanks. :-) > >> Good idea to clean up the calls to >> SharedHeap::heap()->total_collections(). >> >> There are a couple of more places in g1CollectedHeap.cpp where we >> unnecessarily use the SharedHeap:: prefix. Don't know if you want to >> change them as well, of if you think they are good for readability. >> Below is a small patch to remove those usages as well. I'll leave it >> up to you to decide on using it or not. I'm fine with the latest >> webrev as it is. > > I adopted your changes to drop the SharedHeap:: prefix for > ScanningOption and friends (and there was an extra instance of that in > the .hpp file). I think I'll leave > > SharedHeap::process_weak_roots(root_closure, &roots_in_blobs, > non_root_closure); > > as is if that's OK. G1 also has a process_weak_roots() method and, > even though it has a different parameter list, I think the ShredHeap:: > here makes the code a bit more readable (IMHO). It will also guard > against future "surprises" if we change the parameter list of either > process_weak_roots(). > > Latest full webrev here: > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.4/webrev.all/ > > And these are just the above changes: > > http://cr.openjdk.java.net/~tonyp/7129892/webrev.4/webrev.1.G1Latest/ > > Tony > >> Thanks, >> Bengt >> >> diff --git a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> --- a/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> +++ b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> @@ -3171,12 +3171,12 @@ >> >> // We apply the relevant closures to all the oops in the >> // system dictionary, the string table and the code cache. >> - const int so = SharedHeap::SO_AllClasses | >> SharedHeap::SO_Strings | SharedHeap::SO_CodeCache; >> + const int so = SO_AllClasses | SO_Strings | SO_CodeCache; >> >> process_strong_roots(true, // activate StrongRootsScope >> true, // we set "collecting perm gen" >> to true, >> // so we don't reset the dirty >> cards in the perm gen. >> - SharedHeap::ScanningOption(so), // roots >> scanning options >> + ScanningOption(so), // roots scanning options >> &rootsCl, >> &blobsCl, >> &rootsCl); >> @@ -4756,7 +4756,7 @@ >> void >> G1CollectedHeap:: >> g1_process_strong_roots(bool collecting_perm_gen, >> - SharedHeap::ScanningOption so, >> + ScanningOption so, >> OopClosure* scan_non_heap_roots, >> OopsInHeapRegionClosure* scan_rs, >> OopsInGenClosure* scan_perm, >> @@ -4828,7 +4828,7 @@ >> G1CollectedHeap::g1_process_weak_roots(OopClosure* root_closure, >> OopClosure* non_root_closure) { >> CodeBlobToOopClosure roots_in_blobs(root_closure, /*do_marking=*/ >> false); >> - SharedHeap::process_weak_roots(root_closure, &roots_in_blobs, >> non_root_closure); >> + process_weak_roots(root_closure, &roots_in_blobs, non_root_closure); >> } >> >> // Weak Reference Processing support >> >> On 2012-02-08 15:47, Tony Printezis wrote: >>> Bengt, >>> >>> Inline. >>> >>> On 02/08/2012 06:50 AM, Bengt Rutisson wrote: >>>> >>>>> I wrote a test that exposes the issue (when >>>>> +ExplicitGCInvokesConcurrent is used) and I attached it to the CR >>>>> (it initiates marking cycles constantly, I just compare the number >>>>> of System.gc()'s to the number of actual marking cycles in the >>>>> log). I did the first implementation based on the first version of >>>>> your "hum alloc can start a conc cycle" fix and I had to update it >>>>> based on the changes you pushed afterwards. I just reran the test >>>>> to make sure all's still well, and it is: >>>>> >>>>> vanilla: tried to initiate 2610 cycles, 2595 cycles actually >>>>> initiated >>>>> >>>>> with fix: tried to initiate 2613 cycles, 2613 cycles actually >>>>> initiated >>>> >>>> Excellent! Thanks. Sorry for not checking the CR properly before >>>> asking. >>> >>> Np (I should have mentioned the test in the code review request). I >>> couldn't come up with a straightforward way to also test the fix >>> when cycles are initiated by humongous allocations. But, given that >>> that code path also calls collect() I think exercising the code with >>> +ExplicitGCInvokesConcurrent should be enough. >>> >>>>> FWIW, I like the version with the method even if it's just for the >>>>> extra comments which might be helpful to whoever reads the code in >>>>> the future. >>>> >>>> Well, we don't really need the switch to have comments, do we? >>>> Also, I would prefer to have the comments in >>>> should_do_concurrent_full_gc(). That's where I would look for the >>>> information that the comments provide. >>>> >>>> Infact, that method already has a comment in the hpp file: >>>> >>>> // It decides whether an explicit GC should start a concurrent cycle >>>> // instead of doing a STW GC. Currently, a concurrent cycle is >>>> // explicitly started if: >>>> // (a) cause == _gc_locker and +GCLockerInvokesConcurrent, or >>>> // (b) cause == _java_lang_system_gc and >>>> +ExplicitGCInvokesConcurrent. >>>> // (c) cause == _g1_humongous_allocation >>>> bool should_do_concurrent_full_gc(GCCause::Cause cause); >>>> >>>> Mabye just make this comment more detailed? >>> >>> Do you like this version better? >>> >>> http://cr.openjdk.java.net/~tonyp/7129892/webrev.3/ >>> >>> I also noticed that we were calling >>> SharedHeap::heap()->total_collections() from a few places in >>> G1CollectedHeap and we can call total_collections() directly given >>> that G1CH extends SharedHeap. I simplified those. >>> >>> Tony >>> >>>>>> Finally a coding standard question regarding switch statements. >>>>>> The hotspot code in general is not consistent in this case, and >>>>>> neither is the GC code or even the G1 code. But should the "case" >>>>>> statements be indented one level under the "switch" statement? To >>>>>> me that makes sense since the switch statement starts a new code >>>>>> block. I assume you have a different opinion since you wrote it >>>>>> differently, but what is the rational behind it? >>>>>> >>>>>> To exemplify. This: >>>>>> >>>>>> switch (cause) { >>>>>> case GCCause::_gc_locker: return >>>>>> GCLockerInvokesConcurrent; >>>>>> case GCCause::_java_lang_system_gc: return >>>>>> ExplicitGCInvokesConcurrent; >>>>>> case GCCause::_g1_humongous_allocation: return true; >>>>>> default: return false; >>>>>> } >>>>>> >>>>>> would be easier for me to read if it was: >>>>>> >>>>>> switch (cause) { >>>>>> case GCCause::_gc_locker: return >>>>>> GCLockerInvokesConcurrent; >>>>>> case GCCause::_java_lang_system_gc: return >>>>>> ExplicitGCInvokesConcurrent; >>>>>> case GCCause::_g1_humongous_allocation: return true; >>>>>> default: return false; >>>>>> } >>>>> >>>>> I'm OK either way and I do think the latter is a bit nicer. But by >>>>> default emacs does not indent so I went with it. I'll add the >>>>> indentation. >>>> >>>> Great! :-) >>>> >>>> Bengt >>>> >>>>>> Anyway, just ,minor stuff. So, in general: ship it! >>>>> >>>>> Thanks! >>>>> >>>>> Tony >>>>> >>>>>> Bengt >>>>>> >>>>>> On 2012-01-26 20:52, Tony Printezis wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Can I please have a couple of code reviews for the following >>>>>>> change? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~tonyp/7129892/webrev.1/ >>>>>>> >>>>>>> The issue is that a GC attempt that's supposed to explicitly >>>>>>> start a concurrent marking cycle might be unsuccessful (as >>>>>>> another GC might get scheduled first) which will prevent the >>>>>>> cycle from starting. The idea is to retry such unsuccessful >>>>>>> attempts. >>>>>>> >>>>>>> I also changed should_do_concurrent_full_gc() from an >>>>>>> if-statement to a switch statement. I discussed it with Bengt >>>>>>> (the last person to modify that method) and we both think that >>>>>>> the switch statement is more readable. >>>>>>> >>>>>>> BTW, I did a couple of iterations of this fix to address the >>>>>>> slightly different approach Bengt took in the cycle initiation >>>>>>> after hum allocation code (i.e., start the cycle before the >>>>>>> allocation, not after). In the end the current version of >>>>>>> retry_unsuccessful_concurrent_full_gc(), a new method I added, >>>>>>> always returns true for all causes. I'm inclined to leave the >>>>>>> switch in, even just for the comments per cause. I could be >>>>>>> persuaded to replace it with return true; statement though. >>>>>>> >>>>>>> Tony >>>>>>> >>>>>> >>>> >> From igor.veresov at oracle.com Fri Feb 10 12:44:10 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Feb 2012 12:44:10 -0800 Subject: review(M): 7144296: PS: Optimize nmethods processing Message-ID: <93D9A483804940C8BFDF1A9F6B936C0B@oracle.com> This change does two things: 1. Prunes the "scavenge roots in code" list after each minor GC. 2. Promotes objects pointed by code directly into the old gen, instead of ping-ponging them in the survivor spaces. Webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.00/ Thanks! igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120210/eb14d2c3/attachment.html From John.Coomes at oracle.com Fri Feb 10 16:50:06 2012 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 10 Feb 2012 16:50:06 -0800 Subject: review(M): 7144296: PS: Optimize nmethods processing In-Reply-To: <93D9A483804940C8BFDF1A9F6B936C0B@oracle.com> References: <93D9A483804940C8BFDF1A9F6B936C0B@oracle.com> Message-ID: <20277.47934.79701.429047@oracle.com> Igor Veresov (igor.veresov at oracle.com) wrote: > This change does two things: > 1. Prunes the "scavenge roots in code" list after each minor GC. > 2. Promotes objects pointed by code directly into the old gen, instead of ping-ponging them in the survivor spaces. > > Webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.00/ Looks good. Minor suggestion - you could use a typedef and get meaningful names for the closures, e.g., typedef PSRootsClosure PSScavengeRootsClosure; typedef PSRootsClosure PSPromoteRootsClosure; To keep the existing name (PSScavengeRootsClosure) the same at the use points, the template class has to be renamed. I used PSRootsClosure, but any other name would work. -John From igor.veresov at oracle.com Fri Feb 10 17:11:51 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Feb 2012 17:11:51 -0800 Subject: review(M): 7144296: PS: Optimize nmethods processing In-Reply-To: <20277.47934.79701.429047@oracle.com> References: <93D9A483804940C8BFDF1A9F6B936C0B@oracle.com> <20277.47934.79701.429047@oracle.com> Message-ID: Thanks, John! Here the updated webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.01/ igor On Friday, February 10, 2012 at 4:50 PM, John Coomes wrote: > Igor Veresov (igor.veresov at oracle.com (mailto:igor.veresov at oracle.com)) wrote: > > This change does two things: > > 1. Prunes the "scavenge roots in code" list after each minor GC. > > 2. Promotes objects pointed by code directly into the old gen, instead of ping-ponging them in the survivor spaces. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.00/ > > Looks good. Minor suggestion - you could use a typedef and get > meaningful names for the closures, e.g., > > typedef PSRootsClosure PSScavengeRootsClosure; > typedef PSRootsClosure PSPromoteRootsClosure; > > To keep the existing name (PSScavengeRootsClosure) the same at the use > points, the template class has to be renamed. I used PSRootsClosure, > but any other name would work. > > -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120210/1a41bb3c/attachment.html From John.Coomes at oracle.com Fri Feb 10 17:17:07 2012 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 10 Feb 2012 17:17:07 -0800 Subject: review(M): 7144296: PS: Optimize nmethods processing In-Reply-To: References: <93D9A483804940C8BFDF1A9F6B936C0B@oracle.com> <20277.47934.79701.429047@oracle.com> Message-ID: <20277.49555.937769.300473@oracle.com> Igor Veresov (igor.veresov at oracle.com) wrote: > Thanks, John! > Here the updated webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.01/ Looks good to me. And thanks for fixing my typos :-). -John > On Friday, February 10, 2012 at 4:50 PM, John Coomes wrote: > > > Igor Veresov (igor.veresov at oracle.com (mailto:igor.veresov at oracle.com)) wrote: > > > This change does two things: > > > 1. Prunes the "scavenge roots in code" list after each minor GC. > > > 2. Promotes objects pointed by code directly into the old gen, instead of ping-ponging them in the survivor spaces. > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.00/ > > > > Looks good. Minor suggestion - you could use a typedef and get > > meaningful names for the closures, e.g., > > > > typedef PSRootsClosure PSScavengeRootsClosure; > > typedef PSRootsClosure PSPromoteRootsClosure; > > > > To keep the existing name (PSScavengeRootsClosure) the same at the use > > points, the template class has to be renamed. I used PSRootsClosure, > > but any other name would work. > > > > -John > From igor.veresov at oracle.com Fri Feb 10 17:24:05 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 10 Feb 2012 17:24:05 -0800 Subject: review(M): 7144296: PS: Optimize nmethods processing In-Reply-To: <20277.49555.937769.300473@oracle.com> References: <93D9A483804940C8BFDF1A9F6B936C0B@oracle.com> <20277.47934.79701.429047@oracle.com> <20277.49555.937769.300473@oracle.com> Message-ID: Thanks JohnC1 & JohnC2! :) igor On Friday, February 10, 2012 at 5:17 PM, John Coomes wrote: > Igor Veresov (igor.veresov at oracle.com (mailto:igor.veresov at oracle.com)) wrote: > > Thanks, John! > > Here the updated webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.01/ > > > > > Looks good to me. And thanks for fixing my typos :-). > > -John > > > On Friday, February 10, 2012 at 4:50 PM, John Coomes wrote: > > > > > Igor Veresov (igor.veresov at oracle.com (mailto:igor.veresov at oracle.com)) wrote: > > > > This change does two things: > > > > 1. Prunes the "scavenge roots in code" list after each minor GC. > > > > 2. Promotes objects pointed by code directly into the old gen, instead of ping-ponging them in the survivor spaces. > > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7144296/webrev.00/ > > > > > > Looks good. Minor suggestion - you could use a typedef and get > > > meaningful names for the closures, e.g., > > > > > > typedef PSRootsClosure PSScavengeRootsClosure; > > > typedef PSRootsClosure PSPromoteRootsClosure; > > > > > > To keep the existing name (PSScavengeRootsClosure) the same at the use > > > points, the template class has to be renamed. I used PSRootsClosure, > > > but any other name would work. > > > > > > -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120210/15f24b06/attachment.html From igor.veresov at oracle.com Fri Feb 10 20:57:19 2012 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 11 Feb 2012 04:57:19 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7144296: PS: Optimize nmethods processing Message-ID: <20120211045727.0AF5B4747A@hg.openjdk.java.net> Changeset: 95f6641e38e0 Author: iveresov Date: 2012-02-10 17:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/95f6641e38e0 7144296: PS: Optimize nmethods processing Summary: Prunes scavenge roots in code list every young GC, promote objects directly pointed by the code immediately Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp From dean.long at oracle.com Mon Feb 13 14:09:49 2012 From: dean.long at oracle.com (Dean Long) Date: Mon, 13 Feb 2012 14:09:49 -0800 Subject: review request 7140866: assert(covered) failed: Card for end of new region not committed Message-ID: <4F398A2D.4070303@oracle.com> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140866 http://cr.openjdk.java.net/~dlong/7140866/webrev.00/ The problem happens when trying to use a shared archive. If for some reason mapping the shared file fails, we call _rs->resize_covered_region(MemRegion(shared_bottom, shared_bottom)); to undo the earlier call to _rs->resize_covered_region(MemRegion(readonly_bottom, readwrite_end)); Unfortunately the resize code is not prepared to deal with a zero-sized region so an assert fails. Rather than touch the resize code, this fix changes the caller to only call resize_covered_region() once after the shared file is mapped. Tested fix on a particular linux arm platform where the mmap fails 100% of the time due to a different issue. Ran -Xshare:dump first then a few GC tests. dl From tony.printezis at oracle.com Tue Feb 14 07:18:29 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 14 Feb 2012 10:18:29 -0500 Subject: CRR (M): 7132029: G1: mixed GC phase lasts for longer than it should Message-ID: <4F3A7B45.7020106@oracle.com> Hi all, I'd like a couple of (quick please!) code reviews for this change: http://cr.openjdk.java.net/~tonyp/7132029/webrev.0/ The policy that was choosing old regions for collection during mixed GCs was buggy and it could exhibit many strange behaviors, one of which was to go into mixed GC mode, do "mixed GCs" (which they did not actually collect any old regions), and not get out of it for a while while preventing subsequent marking cycles not to start. This frequently caused evac failures and Full GCs. The logic on which old regions to add to the CSet was spread to many places. I simplified that and put it mainly in the loop in the finalize_cset() method (renamed from choose_collection_set(), "finalize" is more descriptive on what the method does). I think the new version is easier to follow. Description of the changes: * I have introduced min and max number of old regions to be added to the CSet of each mixed GC. Max number is calculated as a percentage over the heap size (default: 10% - thanks to Jesper for suggesting to use a heap percentage for this) and ensures that collections will not get super long. Min number is calculated based on a desired mixed GC num after a marking cycle (default: 4) and ensures that each mixed GC will make some progress in collecting old regions (so that the candidate old regions are collected in a timely fashion). * We now don't add any regions with live percentage over a threshold (default: 95%) to the CSet chooser and we do not consider them for collection. * I stopped using the cache in the CSet chooser class (it was used to resort regions according to their latest GC efficiency), since it's not necessary any more: we'll now go through all the candidate old regions in the CSet chooser class and we don't have a heuristic of when to stop mixed GCs based on GC efficiency. * I introduced the notion of "reclaimable bytes" on HeapRegions, which not only includes the predicted garbage bytes on each region, but also the unused space in the area [top,end) which will also be reclaimed. The CSet chooser class now keeps track of the total reclaimable bytes of all the regions that it tracks. If that falls under a certain threshold (default: 1% of the heap) we stop doing mixed GCs as we'll reclaim very little out of the remaining candidate old regions. * I eliminated the case where a mixed GC starts and picks no old regions to collect (I hope!). Now the information on the CSet chooser (remaining region num / remaining reclaimable bytes) can tell us whether we want to do more mixed GCs or not. If we do, it's guaranteed that there will be old regions to collect. Because of that, I removed the _should_revert_to_young_gcs flag as it's not needed any more. It was used so that the CSet choice code could flag that we should stop doing mixed GCs at the end of the GC. Now, we can decide that by just looking at the information on the CSet chooser (the heuristic is encapsulated in the next_gc_should_be_mixed()). * I also changed the policy in the case where a fixed young gen is used. Before, we were a bit arbitrary: during mixed GCs we'd cut the young gen size in half and fill up the rest with old regions. I thought that trying to re-use the "desired mixed GC number" heuristic for this made sense. So, I now add the min number of old regions to each mixed GC (as long as we don't go over the max). I think this is a more reasonable and less arbitrary heuristic to what we had before and it's more consistent with the non-fixed young gen policy. I didn't know whether I should decrease the young gen size for each mixed GC, like how we did before, and by how much. So, I now leave it unchanged (the user decided they want a fixed young gen, they will now always get it!). * Updated all related ergo output to print the new information. Like the marking changes, this change leaves a fair amount of unused code that we can remove. I had to draw the line somewhere on how much I should remove now and how much I should leave for later. I opened a new CR for the remaining cleanup: 7145441: G1: collection set chooser-related cleanup Many thanks to Charlie for doing some last-minute performance testing with my workspace. He was the one who discovered the problem with the never-ending mixed GCs and this fix eliminated the problem. Correctness-testing-wise, I've run overnight with the GC test suite. Thanks, Tony From tony.printezis at oracle.com Tue Feb 14 07:29:51 2012 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Tue, 14 Feb 2012 15:29:51 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Message-ID: <20120214152955.48373474C5@hg.openjdk.java.net> Changeset: caa4652b4414 Author: tonyp Date: 2012-02-14 08:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/caa4652b4414 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Summary: If we try to schedule an initial-mark GC in order to explicit start a conc mark cycle and it gets pre-empted by antoher GC, we should retry the attempt as long as it's appropriate for the GC cause. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp From John.Coomes at oracle.com Tue Feb 14 11:09:03 2012 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 14 Feb 2012 11:09:03 -0800 Subject: review request (m): 6330863 InfiniteList.java intermittent timeout Message-ID: <20282.45391.913824.703384@oracle.com> I'd appreciate reviews of these changes to fix a corner-case that can cause test timeouts with parallel old gc. The review is in two parts; the first part is a prereq that's easily separated so it's in a separate webrev to make reviews of the real fix a bit easier. 1) change the PS invoke methods to return an indicator of whether a gc was done: http://cr.openjdk.java.net/~jcoomes/6330863-invoke-return-val/ 2) adjust the allocation policy: http://cr.openjdk.java.net/~jcoomes/6330863-death-march/ -John From john.cuthbertson at oracle.com Tue Feb 14 11:29:43 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Tue, 14 Feb 2012 19:29:43 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7129514: time warp warnings after 7117303 Message-ID: <20120214192948.1F410474D0@hg.openjdk.java.net> Changeset: d903bf750e9f Author: johnc Date: 2012-01-18 09:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d903bf750e9f 7129514: time warp warnings after 7117303 Summary: Replace calls to os::javaTimeMillis() that are used to update the milliseconds since the last GC to an equivalent that uses a monotonically non-decreasing time source. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp From bengt.rutisson at oracle.com Tue Feb 14 14:24:59 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 14 Feb 2012 23:24:59 +0100 Subject: review request 7140866: assert(covered) failed: Card for end of new region not committed In-Reply-To: <4F398A2D.4070303@oracle.com> References: <4F398A2D.4070303@oracle.com> Message-ID: <4F3ADF3B.8070004@oracle.com> Hi Dean, Thanks for fixing this. Overall I think your change look good, but I have one question: The check on line 282 uses spec()->enable_shared_spaces(), which I think is basically the same as "UseSharedSpaces || DumpSharedSpaces". So, this means that if we are running with "-XX:-UseSharedSpaces -XX:+DumpSharedSpaces" we would before your change do a call to _rs->resize_covered_region(MemRegion(readonly_bottom, readwrite_end)) but after your change we won't do that call, right? Is this an intended change of behavior? I admit that I know too little about this to even know if the above command line makes sense, but it seems to be allowed. Thanks, Bengt On 2012-02-13 23:09, Dean Long wrote: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140866 > > http://cr.openjdk.java.net/~dlong/7140866/webrev.00/ > > The problem happens when trying to use a shared archive. If for some > reason mapping the shared file fails, > we call > > _rs->resize_covered_region(MemRegion(shared_bottom, shared_bottom)); > > to undo the earlier call to > > _rs->resize_covered_region(MemRegion(readonly_bottom, > readwrite_end)); > > Unfortunately the resize code is not prepared to deal with a > zero-sized region so an assert fails. > Rather than touch the resize code, this fix changes the caller to only > call resize_covered_region() > once after the shared file is mapped. > > Tested fix on a particular linux arm platform where the mmap fails > 100% of the time due to a different issue. > Ran -Xshare:dump first then a few GC tests. > > dl From ysr1729 at gmail.com Tue Feb 14 16:30:17 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 14 Feb 2012 16:30:17 -0800 Subject: review request 7140866: assert(covered) failed: Card for end of new region not committed In-Reply-To: <4F398A2D.4070303@oracle.com> References: <4F398A2D.4070303@oracle.com> Message-ID: Looks good to me. -- ramki (openjdk: ysr) On Mon, Feb 13, 2012 at 2:09 PM, Dean Long wrote: > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7140866 > > http://cr.openjdk.java.net/~**dlong/7140866/webrev.00/ > > The problem happens when trying to use a shared archive. If for some > reason mapping the shared file fails, > we call > > _rs->resize_covered_region(**MemRegion(shared_bottom, shared_bottom)); > > to undo the earlier call to > > _rs->resize_covered_region(**MemRegion(readonly_bottom, > readwrite_end)); > > Unfortunately the resize code is not prepared to deal with a zero-sized > region so an assert fails. > Rather than touch the resize code, this fix changes the caller to only > call resize_covered_region() > once after the shared file is mapped. > > Tested fix on a particular linux arm platform where the mmap fails 100% of > the time due to a different issue. > Ran -Xshare:dump first then a few GC tests. > > dl > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120214/124fc308/attachment.html From bengt.rutisson at oracle.com Tue Feb 14 20:55:14 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 15 Feb 2012 05:55:14 +0100 Subject: review request 7140866: assert(covered) failed: Card for end of new region not committed In-Reply-To: <4F3ADF3B.8070004@oracle.com> References: <4F398A2D.4070303@oracle.com> <4F3ADF3B.8070004@oracle.com> Message-ID: <4F3B3AB2.1070506@oracle.com> Hi again Dean, Please disregard my last email. The changed behavior I was thinking about was actually for "-XX:-UseSharedSpaces -XX:-DumpSharedSpaces", but in that case I think we bail out already at line 207 and never get in to the code you changed. 207 if (spec()->enable_shared_spaces()) { Sorry for the confusion. Change looks good! Ship it! (Copyright year should be 2012.) Bengt On 2012-02-14 23:24, Bengt Rutisson wrote: > > Hi Dean, > > Thanks for fixing this. Overall I think your change look good, but I > have one question: > > The check on line 282 uses spec()->enable_shared_spaces(), which I > think is basically the same as "UseSharedSpaces || DumpSharedSpaces". > So, this means that if we are running with "-XX:-UseSharedSpaces > -XX:+DumpSharedSpaces" we would before your change do a call to > > _rs->resize_covered_region(MemRegion(readonly_bottom, readwrite_end)) > > but after your change we won't do that call, right? Is this an > intended change of behavior? > > I admit that I know too little about this to even know if the above > command line makes sense, but it seems to be allowed. > > Thanks, > Bengt > > On 2012-02-13 23:09, Dean Long wrote: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140866 >> >> http://cr.openjdk.java.net/~dlong/7140866/webrev.00/ >> >> The problem happens when trying to use a shared archive. If for some >> reason mapping the shared file fails, >> we call >> >> _rs->resize_covered_region(MemRegion(shared_bottom, shared_bottom)); >> >> to undo the earlier call to >> >> _rs->resize_covered_region(MemRegion(readonly_bottom, >> readwrite_end)); >> >> Unfortunately the resize code is not prepared to deal with a >> zero-sized region so an assert fails. >> Rather than touch the resize code, this fix changes the caller to >> only call resize_covered_region() >> once after the shared file is mapped. >> >> Tested fix on a particular linux arm platform where the mmap fails >> 100% of the time due to a different issue. >> Ran -Xshare:dump first then a few GC tests. >> >> dl > From dean.long at oracle.com Tue Feb 14 21:02:52 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 14 Feb 2012 21:02:52 -0800 Subject: review request 7140866: assert(covered) failed: Card for end of new region not committed In-Reply-To: References: <4F398A2D.4070303@oracle.com> Message-ID: <4F3B3C7C.1030601@oracle.com> Thanks Ramki. dl On 2/14/2012 4:30 PM, Srinivas Ramakrishna wrote: > Looks good to me. > > -- ramki (openjdk: ysr) > > On Mon, Feb 13, 2012 at 2:09 PM, Dean Long > wrote: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140866 > > http://cr.openjdk.java.net/~dlong/7140866/webrev.00/ > > > The problem happens when trying to use a shared archive. If for > some reason mapping the shared file fails, > we call > > _rs->resize_covered_region(MemRegion(shared_bottom, > shared_bottom)); > > to undo the earlier call to > > _rs->resize_covered_region(MemRegion(readonly_bottom, > readwrite_end)); > > Unfortunately the resize code is not prepared to deal with a > zero-sized region so an assert fails. > Rather than touch the resize code, this fix changes the caller to > only call resize_covered_region() > once after the shared file is mapped. > > Tested fix on a particular linux arm platform where the mmap fails > 100% of the time due to a different issue. > Ran -Xshare:dump first then a few GC tests. > > dl > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120214/61a529aa/attachment.html From dean.long at oracle.com Tue Feb 14 21:04:39 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 14 Feb 2012 21:04:39 -0800 Subject: review request 7140866: assert(covered) failed: Card for end of new region not committed In-Reply-To: <4F3B3AB2.1070506@oracle.com> References: <4F398A2D.4070303@oracle.com> <4F3ADF3B.8070004@oracle.com> <4F3B3AB2.1070506@oracle.com> Message-ID: <4F3B3CE7.10804@oracle.com> On 2/14/2012 8:55 PM, Bengt Rutisson wrote: > > Hi again Dean, > > Please disregard my last email. The changed behavior I was thinking > about was actually for "-XX:-UseSharedSpaces -XX:-DumpSharedSpaces", > but in that case I think we bail out already at line 207 and never get > in to the code you changed. > > 207 if (spec()->enable_shared_spaces()) { > > Sorry for the confusion. > > Change looks good! Ship it! > Great. Thanks for the review. > (Copyright year should be 2012.) > Thanks for catching that. Fixed. dl > Bengt > > On 2012-02-14 23:24, Bengt Rutisson wrote: >> >> Hi Dean, >> >> Thanks for fixing this. Overall I think your change look good, but I >> have one question: >> >> The check on line 282 uses spec()->enable_shared_spaces(), which I >> think is basically the same as "UseSharedSpaces || DumpSharedSpaces". >> So, this means that if we are running with "-XX:-UseSharedSpaces >> -XX:+DumpSharedSpaces" we would before your change do a call to >> >> _rs->resize_covered_region(MemRegion(readonly_bottom, readwrite_end)) >> >> but after your change we won't do that call, right? Is this an >> intended change of behavior? >> >> I admit that I know too little about this to even know if the above >> command line makes sense, but it seems to be allowed. >> >> Thanks, >> Bengt >> >> On 2012-02-13 23:09, Dean Long wrote: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140866 >>> >>> http://cr.openjdk.java.net/~dlong/7140866/webrev.00/ >>> >>> The problem happens when trying to use a shared archive. If for >>> some reason mapping the shared file fails, >>> we call >>> >>> _rs->resize_covered_region(MemRegion(shared_bottom, >>> shared_bottom)); >>> >>> to undo the earlier call to >>> >>> _rs->resize_covered_region(MemRegion(readonly_bottom, >>> readwrite_end)); >>> >>> Unfortunately the resize code is not prepared to deal with a >>> zero-sized region so an assert fails. >>> Rather than touch the resize code, this fix changes the caller to >>> only call resize_covered_region() >>> once after the shared file is mapped. >>> >>> Tested fix on a particular linux arm platform where the mmap fails >>> 100% of the time due to a different issue. >>> Ran -Xshare:dump first then a few GC tests. >>> >>> dl >> > From bengt.rutisson at oracle.com Wed Feb 15 00:46:16 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 15 Feb 2012 09:46:16 +0100 Subject: CRR (M): 7132029: G1: mixed GC phase lasts for longer than it should In-Reply-To: <4F3A7B45.7020106@oracle.com> References: <4F3A7B45.7020106@oracle.com> Message-ID: <4F3B70D8.5090008@oracle.com> Hi Tony, I really like this cleanup! Thanks for fixing it. Some comments: collectionSetChooser.hpp: _numMarkedRegions is kind of a confusing name to me. It does not contain all the marked regions. It contains all the old regions that we would like to include in the collection set. How about _num_selected_regions or even _num_selected_old_regions? I think the remove(HeapRegion* hr) method is kind of strange. I understand the need for peek() from finalize_cset(), but I think it is strange that the remove() dependes on the code first calling peek(). I'd prefer if we could make this more iterator style or at least change remove() to someting like pop() that will return the next HeapRegion instead of taking it as a parameter. collectionSetChooser.cpp: Why is the method CollectionSetChooser::updateAfterFullCollection() needed? Can't G1CollectorPolicy::record_full_collection_end() do _collectionSetChooser->clearMarkedHeapRegions() just like G1CollectorPolicy::record_concurrent_mark_cleanup_end() does? g1_globals.hpp: It seems to me that at least the G1MaxMixedGCNum and the G1OldCSetRegionThresholdPercent can be things that end users might need to tweak until we have the heuristics more thoroughly tested out. Would it be ok to make them available in product builds? Maybe as experiemental flags? g1CollectorPolicy.cpp: if (next_gc_should_be_mixed("end of young GC")) { ergo_verbose0(ErgoMixedGCs, "start mixed GCs", ergo_format_reason("appropriate old regions available")); set_gcs_are_young(false); } else { ergo_verbose0(ErgoMixedGCs, "do not start mixed GCs", ergo_format_reason("appropriate old regions available")); } I think the ergo_verbose message in the else case at lines 1490-1492 should say "appropriate old regions not available", right? We log the ergo decisions in next_gc_should_be_mixed(). Will it not be duplicate information to log it in G1CollectorPolicy::record_collection_pause_end() as well? Bengt On 2012-02-14 16:18, Tony Printezis wrote: > Hi all, > > I'd like a couple of (quick please!) code reviews for this change: > > http://cr.openjdk.java.net/~tonyp/7132029/webrev.0/ > > The policy that was choosing old regions for collection during mixed > GCs was buggy and it could exhibit many strange behaviors, one of > which was to go into mixed GC mode, do "mixed GCs" (which they did not > actually collect any old regions), and not get out of it for a while > while preventing subsequent marking cycles not to start. This > frequently caused evac failures and Full GCs. > > The logic on which old regions to add to the CSet was spread to many > places. I simplified that and put it mainly in the loop in the > finalize_cset() method (renamed from choose_collection_set(), > "finalize" is more descriptive on what the method does). I think the > new version is easier to follow. > > Description of the changes: > > * I have introduced min and max number of old regions to be added to > the CSet of each mixed GC. Max number is calculated as a percentage > over the heap size (default: 10% - thanks to Jesper for suggesting to > use a heap percentage for this) and ensures that collections will not > get super long. Min number is calculated based on a desired mixed GC > num after a marking cycle (default: 4) and ensures that each mixed GC > will make some progress in collecting old regions (so that the > candidate old regions are collected in a timely fashion). > > * We now don't add any regions with live percentage over a threshold > (default: 95%) to the CSet chooser and we do not consider them for > collection. > > * I stopped using the cache in the CSet chooser class (it was used to > resort regions according to their latest GC efficiency), since it's > not necessary any more: we'll now go through all the candidate old > regions in the CSet chooser class and we don't have a heuristic of > when to stop mixed GCs based on GC efficiency. > > * I introduced the notion of "reclaimable bytes" on HeapRegions, which > not only includes the predicted garbage bytes on each region, but also > the unused space in the area [top,end) which will also be reclaimed. > The CSet chooser class now keeps track of the total reclaimable bytes > of all the regions that it tracks. If that falls under a certain > threshold (default: 1% of the heap) we stop doing mixed GCs as we'll > reclaim very little out of the remaining candidate old regions. > > * I eliminated the case where a mixed GC starts and picks no old > regions to collect (I hope!). Now the information on the CSet chooser > (remaining region num / remaining reclaimable bytes) can tell us > whether we want to do more mixed GCs or not. If we do, it's guaranteed > that there will be old regions to collect. Because of that, I removed > the _should_revert_to_young_gcs flag as it's not needed any more. It > was used so that the CSet choice code could flag that we should stop > doing mixed GCs at the end of the GC. Now, we can decide that by just > looking at the information on the CSet chooser (the heuristic is > encapsulated in the next_gc_should_be_mixed()). > > * I also changed the policy in the case where a fixed young gen is > used. Before, we were a bit arbitrary: during mixed GCs we'd cut the > young gen size in half and fill up the rest with old regions. I > thought that trying to re-use the "desired mixed GC number" heuristic > for this made sense. So, I now add the min number of old regions to > each mixed GC (as long as we don't go over the max). I think this is a > more reasonable and less arbitrary heuristic to what we had before and > it's more consistent with the non-fixed young gen policy. I didn't > know whether I should decrease the young gen size for each mixed GC, > like how we did before, and by how much. So, I now leave it unchanged > (the user decided they want a fixed young gen, they will now always > get it!). > > * Updated all related ergo output to print the new information. > > Like the marking changes, this change leaves a fair amount of unused > code that we can remove. I had to draw the line somewhere on how much > I should remove now and how much I should leave for later. I opened a > new CR for the remaining cleanup: > > 7145441: G1: collection set chooser-related cleanup > > Many thanks to Charlie for doing some last-minute performance testing > with my workspace. He was the one who discovered the problem with the > never-ending mixed GCs and this fix eliminated the problem. > Correctness-testing-wise, I've run overnight with the GC test suite. > > Thanks, > > Tony > > From stefan.karlsson at oracle.com Wed Feb 15 03:40:49 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 15 Feb 2012 12:40:49 +0100 Subject: review request (m): 6330863 InfiniteList.java intermittent timeout In-Reply-To: <20282.45391.913824.703384@oracle.com> References: <20282.45391.913824.703384@oracle.com> Message-ID: <4F3B99C1.60503@oracle.com> Hi John, This looks good, but I have a couple of style change suggestions. See inlined: On 02/14/2012 08:09 PM, John Coomes wrote: > I'd appreciate reviews of these changes to fix a corner-case that > can cause test timeouts with parallel old gc. > > The review is in two parts; the first part is a prereq that's easily > separated so it's in a separate webrev to make reviews of the real fix > a bit easier. > > 1) change the PS invoke methods to return an indicator of whether a gc > was done: > > http://cr.openjdk.java.net/~jcoomes/6330863-invoke-return-val/ http://cr.openjdk.java.net/~jcoomes/6330863-invoke-return-val/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.frames.html 229 - bool scavenge_was_done = PSScavenge::invoke_no_policy(); 229 + const bool need_full_gc = !PSScavenge::invoke_no_policy() || 230 + policy->should_full_GC(heap->old_gen()->free_in_bytes()); 231 + bool did_full_gc = false; IMHO, inlining the invoke_no_policy call here makes it harder to read. Would you mind keeping scavenge_was_done and use it on line 229? 223-250 ... I think it would be good for readability to extract counter update code out of the full GC calling code. For example: if (UsePerfData) { PSGCAdaptivePolicyCounters* const counters = heap->gc_policy_counters(); if (need_full_gc) { counters->update_full_follows_scavenge(full_follows_scavenge); } else { counters->update_full_follows_scavenge(0); } } if (need_full_gc) { GCCauseSetter gccs(heap, GCCause::_adaptive_size_policy); CollectorPolicy* cp = heap->collector_policy(); const bool clear_all_softrefs = cp->should_clear_all_soft_refs(); if (UseParallelOldGC) { did_full_gc = PSParallelCompact::invoke_no_policy(clear_all_softrefs); } else { did_full_gc = PSMarkSweep::invoke_no_policy(clear_all_softrefs); } } > > 2) adjust the allocation policy: > > http://cr.openjdk.java.net/~jcoomes/6330863-death-march/ http://cr.openjdk.java.net/~jcoomes/6330863-death-march/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.frames.html 421 if (result != NULL) return result; and 425 if (result != NULL) return result; Could you keep the return statements on a separate line? StefanK > > -John From tony.printezis at oracle.com Wed Feb 15 05:47:56 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 15 Feb 2012 08:47:56 -0500 Subject: CRR (M): 7132029: G1: mixed GC phase lasts for longer than it should In-Reply-To: <4F3B70D8.5090008@oracle.com> References: <4F3A7B45.7020106@oracle.com> <4F3B70D8.5090008@oracle.com> Message-ID: <4F3BB78C.4050005@oracle.com> Bengt, Thanks for looking at this at such short notice! Inline. On 02/15/2012 03:46 AM, Bengt Rutisson wrote: > > Hi Tony, > > I really like this cleanup! Thanks for fixing it. > > Some comments: > > collectionSetChooser.hpp: > > _numMarkedRegions is kind of a confusing name to me. It does not > contain all the marked regions. Well, I left it as it was. And it's also not called _numAllMarkedRegions. :-) How about I just call it _length (and _curMarkedIndex -> _curr_index)? > It contains all the old regions that we would like to include in the > collection set. How about _num_selected_regions or even > _num_selected_old_regions? > > I think the remove(HeapRegion* hr) method is kind of strange. I > understand the need for peek() from finalize_cset(), but I think it is > strange that the remove() dependes on the code first calling peek(). > I'd prefer if we could make this more iterator style or at least > change remove() to someting like pop() that will return the next > HeapRegion instead of taking it as a parameter. Well, peek() and remove() are only called from the loop in finalize_cset(), so they are tailored for that. I originally had remove() with no parameters that just removed the current region. I then thought of passing the region as a parameter mainly to do sanity testing (i.e., the region that it's being removed is the one we think it should be removed). And I then realized that, given we already have the region, there's no point in actually re-reading it from the array. Si we . I could generalize remove() to accept hr optionally, but given that we only use it when we know what the region to be removed is, I don't see the point. Also, I'm not sure that using HeapRegion* pop() is appropriate either, given that the caller doesn't need to be given the region that just got removed (it already knows which one it is). Also note that the peek() / remove() pattern is similar to the ListIterator class in Java which has a E next() (equivalent to peek()) and void remove(). I just added extra information to the remove() method. (What I'm trying to say is: there's precedence to such a pattern.) > > collectionSetChooser.cpp: > > Why is the method CollectionSetChooser::updateAfterFullCollection() > needed? Can't G1CollectorPolicy::record_full_collection_end() do > _collectionSetChooser->clearMarkedHeapRegions() just like > G1CollectorPolicy::record_concurrent_mark_cleanup_end() does? I'm OK either way. Maybe we used to do more in updateAfterFullCollection() once upon the time but we don't do any more. I'll remove it and replace it with a direct call to clearMarkedHeapRegions() as you suggested. > g1_globals.hpp: > > It seems to me that at least the G1MaxMixedGCNum and the > G1OldCSetRegionThresholdPercent can be things that end users might > need to tweak until we have the heuristics more thoroughly tested out. > Would it be ok to make them available in product builds? Maybe as > experiemental flags? Actually, it might be helpful to expose all four develop flags I added to the user so that they can control different aspects of the heuristics: a) G1OldCSetRegionLiveThresholdPercent and G1OldReclaimableThresholdPercent: control how much free space to "sacrifice" in order to decrease mixed GC times (BTW, it'd be nice if we could somehow combine these two.) b) G1MaxMixedGCNum: control how promptly G1 will collect the candidate old regions: more promptly -> more free space is made available quicker, less promptly -> each mixed GC might be shorter. c) G1OldCSetRegionThresholdPercent: control how aggressive G1 will be in collecting old regions during each mixed GC: more aggressive -> more free space is made available quicker, less promptly -> each mixed GC might be shorter. (come to think about it, maybe we should think of combining the last two too!) But before we expose these we need to a) get a better understanding of what effect each has on G1's performance and b) find better names for them. :-) (I didn't try very hard, as I assumed that they will be develop parameters.) > g1CollectorPolicy.cpp: > > if (next_gc_should_be_mixed("end of young GC")) { > ergo_verbose0(ErgoMixedGCs, > "start mixed GCs", > ergo_format_reason("appropriate old regions > available")); > set_gcs_are_young(false); > } else { > ergo_verbose0(ErgoMixedGCs, > "do not start mixed GCs", > ergo_format_reason("appropriate old regions > available")); > } > > I think the ergo_verbose message in the else case at lines 1490-1492 > should say "appropriate old regions not available", right? Correct, thanks. John also caught that. > We log the ergo decisions in next_gc_should_be_mixed(). Will it not be > duplicate information to log it in > G1CollectorPolicy::record_collection_pause_end() as well? That's a good point. This is what the output looks like right now: 3.708: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: appropriate old regions available, phase: end of young GC, remaining old regions: 16 regions, reclaimable: 9803640 bytes (29.22 %), threshold: 1.00 %] 3.708: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: appropriate old regions available] 23M->18M(32M), 0.0411940 secs] ... 3.938: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: appropriate old regions available, phase: end of mixed GC, remaining old regions: 12 regions, reclaimable: 5823976 bytes (17.36 %), threshold: 1.00 %] 3.938: [G1Ergonomics (Mixed GCs) do not end mixed GCs, reason: appropriate old regions available] 23M->15M(32M), 0.0322850 secs] I'll see how easy will be to parametarize next_gc_should_be_mixed() with the "do" / "do not" action strings (instead of the phase_str). I'll send out a new webrev in a bit. Tony > Bengt > > > On 2012-02-14 16:18, Tony Printezis wrote: >> Hi all, >> >> I'd like a couple of (quick please!) code reviews for this change: >> >> http://cr.openjdk.java.net/~tonyp/7132029/webrev.0/ >> >> The policy that was choosing old regions for collection during mixed >> GCs was buggy and it could exhibit many strange behaviors, one of >> which was to go into mixed GC mode, do "mixed GCs" (which they did >> not actually collect any old regions), and not get out of it for a >> while while preventing subsequent marking cycles not to start. This >> frequently caused evac failures and Full GCs. >> >> The logic on which old regions to add to the CSet was spread to many >> places. I simplified that and put it mainly in the loop in the >> finalize_cset() method (renamed from choose_collection_set(), >> "finalize" is more descriptive on what the method does). I think the >> new version is easier to follow. >> >> Description of the changes: >> >> * I have introduced min and max number of old regions to be added to >> the CSet of each mixed GC. Max number is calculated as a percentage >> over the heap size (default: 10% - thanks to Jesper for suggesting to >> use a heap percentage for this) and ensures that collections will not >> get super long. Min number is calculated based on a desired mixed GC >> num after a marking cycle (default: 4) and ensures that each mixed GC >> will make some progress in collecting old regions (so that the >> candidate old regions are collected in a timely fashion). >> >> * We now don't add any regions with live percentage over a threshold >> (default: 95%) to the CSet chooser and we do not consider them for >> collection. >> >> * I stopped using the cache in the CSet chooser class (it was used to >> resort regions according to their latest GC efficiency), since it's >> not necessary any more: we'll now go through all the candidate old >> regions in the CSet chooser class and we don't have a heuristic of >> when to stop mixed GCs based on GC efficiency. >> >> * I introduced the notion of "reclaimable bytes" on HeapRegions, >> which not only includes the predicted garbage bytes on each region, >> but also the unused space in the area [top,end) which will also be >> reclaimed. The CSet chooser class now keeps track of the total >> reclaimable bytes of all the regions that it tracks. If that falls >> under a certain threshold (default: 1% of the heap) we stop doing >> mixed GCs as we'll reclaim very little out of the remaining candidate >> old regions. >> >> * I eliminated the case where a mixed GC starts and picks no old >> regions to collect (I hope!). Now the information on the CSet chooser >> (remaining region num / remaining reclaimable bytes) can tell us >> whether we want to do more mixed GCs or not. If we do, it's >> guaranteed that there will be old regions to collect. Because of >> that, I removed the _should_revert_to_young_gcs flag as it's not >> needed any more. It was used so that the CSet choice code could flag >> that we should stop doing mixed GCs at the end of the GC. Now, we can >> decide that by just looking at the information on the CSet chooser >> (the heuristic is encapsulated in the next_gc_should_be_mixed()). >> >> * I also changed the policy in the case where a fixed young gen is >> used. Before, we were a bit arbitrary: during mixed GCs we'd cut the >> young gen size in half and fill up the rest with old regions. I >> thought that trying to re-use the "desired mixed GC number" heuristic >> for this made sense. So, I now add the min number of old regions to >> each mixed GC (as long as we don't go over the max). I think this is >> a more reasonable and less arbitrary heuristic to what we had before >> and it's more consistent with the non-fixed young gen policy. I >> didn't know whether I should decrease the young gen size for each >> mixed GC, like how we did before, and by how much. So, I now leave it >> unchanged (the user decided they want a fixed young gen, they will >> now always get it!). >> >> * Updated all related ergo output to print the new information. >> >> Like the marking changes, this change leaves a fair amount of unused >> code that we can remove. I had to draw the line somewhere on how much >> I should remove now and how much I should leave for later. I opened a >> new CR for the remaining cleanup: >> >> 7145441: G1: collection set chooser-related cleanup >> >> Many thanks to Charlie for doing some last-minute performance testing >> with my workspace. He was the one who discovered the problem with the >> never-ending mixed GCs and this fix eliminated the problem. >> Correctness-testing-wise, I've run overnight with the GC test suite. >> >> Thanks, >> >> Tony >> >> > From bengt.rutisson at oracle.com Wed Feb 15 06:28:51 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 15 Feb 2012 15:28:51 +0100 Subject: CRR (M): 7132029: G1: mixed GC phase lasts for longer than it should In-Reply-To: <4F3BB78C.4050005@oracle.com> References: <4F3A7B45.7020106@oracle.com> <4F3B70D8.5090008@oracle.com> <4F3BB78C.4050005@oracle.com> Message-ID: <4F3BC123.5070405@oracle.com> Tony, Very short reply inline. On 2012-02-15 14:47, Tony Printezis wrote: > Bengt, > > Thanks for looking at this at such short notice! Inline. > > On 02/15/2012 03:46 AM, Bengt Rutisson wrote: >> >> Hi Tony, >> >> I really like this cleanup! Thanks for fixing it. >> >> Some comments: >> >> collectionSetChooser.hpp: >> >> _numMarkedRegions is kind of a confusing name to me. It does not >> contain all the marked regions. > > Well, I left it as it was. And it's also not called > _numAllMarkedRegions. :-) How about I just call it _length (and > _curMarkedIndex -> _curr_index)? OK. > >> It contains all the old regions that we would like to include in the >> collection set. How about _num_selected_regions or even >> _num_selected_old_regions? >> >> I think the remove(HeapRegion* hr) method is kind of strange. I >> understand the need for peek() from finalize_cset(), but I think it >> is strange that the remove() dependes on the code first calling >> peek(). I'd prefer if we could make this more iterator style or at >> least change remove() to someting like pop() that will return the >> next HeapRegion instead of taking it as a parameter. > > Well, peek() and remove() are only called from the loop in > finalize_cset(), so they are tailored for that. I originally had > remove() with no parameters that just removed the current region. I > then thought of passing the region as a parameter mainly to do sanity > testing (i.e., the region that it's being removed is the one we think > it should be removed). And I then realized that, given we already have > the region, there's no point in actually re-reading it from the array. > Si we . I could generalize remove() to accept hr optionally, but given > that we only use it when we know what the region to be removed is, I > don't see the point. Also, I'm not sure that using HeapRegion* pop() > is appropriate either, given that the caller doesn't need to be given > the region that just got removed (it already knows which one it is). > > Also note that the peek() / remove() pattern is similar to the > ListIterator class in Java which has a E next() (equivalent to peek()) > and void remove(). I just added extra information to the remove() > method. (What I'm trying to say is: there's precedence to such a > pattern.) I'm sorry. I still don't like the remove() method. Can we inline the "_remainingReclaimableBytes -= hr->reclaimable_bytes();" where we now call remove() and then call remove() something like move_to_next() without any HeapRegion at all? Not sure that this was a good suggestion... Bengt > >> >> collectionSetChooser.cpp: >> >> Why is the method CollectionSetChooser::updateAfterFullCollection() >> needed? Can't G1CollectorPolicy::record_full_collection_end() do >> _collectionSetChooser->clearMarkedHeapRegions() just like >> G1CollectorPolicy::record_concurrent_mark_cleanup_end() does? > > I'm OK either way. Maybe we used to do more in > updateAfterFullCollection() once upon the time but we don't do any > more. I'll remove it and replace it with a direct call to > clearMarkedHeapRegions() as you suggested. > >> g1_globals.hpp: >> >> It seems to me that at least the G1MaxMixedGCNum and the >> G1OldCSetRegionThresholdPercent can be things that end users might >> need to tweak until we have the heuristics more thoroughly tested >> out. Would it be ok to make them available in product builds? Maybe >> as experiemental flags? > > Actually, it might be helpful to expose all four develop flags I added > to the user so that they can control different aspects of the heuristics: > > a) G1OldCSetRegionLiveThresholdPercent and > G1OldReclaimableThresholdPercent: control how much free space to > "sacrifice" in order to decrease mixed GC times (BTW, it'd be nice if > we could somehow combine these two.) > > b) G1MaxMixedGCNum: control how promptly G1 will collect the candidate > old regions: more promptly -> more free space is made available > quicker, less promptly -> each mixed GC might be shorter. > > c) G1OldCSetRegionThresholdPercent: control how aggressive G1 will be > in collecting old regions during each mixed GC: more aggressive -> > more free space is made available quicker, less promptly -> each mixed > GC might be shorter. > > (come to think about it, maybe we should think of combining the last > two too!) > > But before we expose these we need to a) get a better understanding of > what effect each has on G1's performance and b) find better names for > them. :-) (I didn't try very hard, as I assumed that they will be > develop parameters.) > >> g1CollectorPolicy.cpp: >> >> if (next_gc_should_be_mixed("end of young GC")) { >> ergo_verbose0(ErgoMixedGCs, >> "start mixed GCs", >> ergo_format_reason("appropriate old regions >> available")); >> set_gcs_are_young(false); >> } else { >> ergo_verbose0(ErgoMixedGCs, >> "do not start mixed GCs", >> ergo_format_reason("appropriate old regions >> available")); >> } >> >> I think the ergo_verbose message in the else case at lines 1490-1492 >> should say "appropriate old regions not available", right? > > Correct, thanks. John also caught that. > >> We log the ergo decisions in next_gc_should_be_mixed(). Will it not >> be duplicate information to log it in >> G1CollectorPolicy::record_collection_pause_end() as well? > > That's a good point. This is what the output looks like right now: > > 3.708: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: > appropriate old regions available, phase: end of young GC, remaining > old regions: 16 regions, reclaimable: 9803640 bytes (29.22 %), > threshold: 1.00 %] > 3.708: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: appropriate > old regions available] > 23M->18M(32M), 0.0411940 secs] > > ... > > 3.938: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: > appropriate old regions available, phase: end of mixed GC, remaining > old regions: 12 regions, reclaimable: 5823976 bytes (17.36 %), > threshold: 1.00 %] > 3.938: [G1Ergonomics (Mixed GCs) do not end mixed GCs, reason: > appropriate old regions available] > 23M->15M(32M), 0.0322850 secs] > > I'll see how easy will be to parametarize next_gc_should_be_mixed() > with the "do" / "do not" action strings (instead of the phase_str). > > I'll send out a new webrev in a bit. > > Tony > >> Bengt >> >> >> On 2012-02-14 16:18, Tony Printezis wrote: >>> Hi all, >>> >>> I'd like a couple of (quick please!) code reviews for this change: >>> >>> http://cr.openjdk.java.net/~tonyp/7132029/webrev.0/ >>> >>> The policy that was choosing old regions for collection during mixed >>> GCs was buggy and it could exhibit many strange behaviors, one of >>> which was to go into mixed GC mode, do "mixed GCs" (which they did >>> not actually collect any old regions), and not get out of it for a >>> while while preventing subsequent marking cycles not to start. This >>> frequently caused evac failures and Full GCs. >>> >>> The logic on which old regions to add to the CSet was spread to many >>> places. I simplified that and put it mainly in the loop in the >>> finalize_cset() method (renamed from choose_collection_set(), >>> "finalize" is more descriptive on what the method does). I think the >>> new version is easier to follow. >>> >>> Description of the changes: >>> >>> * I have introduced min and max number of old regions to be added to >>> the CSet of each mixed GC. Max number is calculated as a percentage >>> over the heap size (default: 10% - thanks to Jesper for suggesting >>> to use a heap percentage for this) and ensures that collections will >>> not get super long. Min number is calculated based on a desired >>> mixed GC num after a marking cycle (default: 4) and ensures that >>> each mixed GC will make some progress in collecting old regions (so >>> that the candidate old regions are collected in a timely fashion). >>> >>> * We now don't add any regions with live percentage over a threshold >>> (default: 95%) to the CSet chooser and we do not consider them for >>> collection. >>> >>> * I stopped using the cache in the CSet chooser class (it was used >>> to resort regions according to their latest GC efficiency), since >>> it's not necessary any more: we'll now go through all the candidate >>> old regions in the CSet chooser class and we don't have a heuristic >>> of when to stop mixed GCs based on GC efficiency. >>> >>> * I introduced the notion of "reclaimable bytes" on HeapRegions, >>> which not only includes the predicted garbage bytes on each region, >>> but also the unused space in the area [top,end) which will also be >>> reclaimed. The CSet chooser class now keeps track of the total >>> reclaimable bytes of all the regions that it tracks. If that falls >>> under a certain threshold (default: 1% of the heap) we stop doing >>> mixed GCs as we'll reclaim very little out of the remaining >>> candidate old regions. >>> >>> * I eliminated the case where a mixed GC starts and picks no old >>> regions to collect (I hope!). Now the information on the CSet >>> chooser (remaining region num / remaining reclaimable bytes) can >>> tell us whether we want to do more mixed GCs or not. If we do, it's >>> guaranteed that there will be old regions to collect. Because of >>> that, I removed the _should_revert_to_young_gcs flag as it's not >>> needed any more. It was used so that the CSet choice code could flag >>> that we should stop doing mixed GCs at the end of the GC. Now, we >>> can decide that by just looking at the information on the CSet >>> chooser (the heuristic is encapsulated in the >>> next_gc_should_be_mixed()). >>> >>> * I also changed the policy in the case where a fixed young gen is >>> used. Before, we were a bit arbitrary: during mixed GCs we'd cut the >>> young gen size in half and fill up the rest with old regions. I >>> thought that trying to re-use the "desired mixed GC number" >>> heuristic for this made sense. So, I now add the min number of old >>> regions to each mixed GC (as long as we don't go over the max). I >>> think this is a more reasonable and less arbitrary heuristic to what >>> we had before and it's more consistent with the non-fixed young gen >>> policy. I didn't know whether I should decrease the young gen size >>> for each mixed GC, like how we did before, and by how much. So, I >>> now leave it unchanged (the user decided they want a fixed young >>> gen, they will now always get it!). >>> >>> * Updated all related ergo output to print the new information. >>> >>> Like the marking changes, this change leaves a fair amount of unused >>> code that we can remove. I had to draw the line somewhere on how >>> much I should remove now and how much I should leave for later. I >>> opened a new CR for the remaining cleanup: >>> >>> 7145441: G1: collection set chooser-related cleanup >>> >>> Many thanks to Charlie for doing some last-minute performance >>> testing with my workspace. He was the one who discovered the problem >>> with the never-ending mixed GCs and this fix eliminated the problem. >>> Correctness-testing-wise, I've run overnight with the GC test suite. >>> >>> Thanks, >>> >>> Tony >>> >>> >> From tony.printezis at oracle.com Wed Feb 15 07:19:21 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 15 Feb 2012 10:19:21 -0500 Subject: CRR (M): 7132029: G1: mixed GC phase lasts for longer than it should In-Reply-To: <4F3BB78C.4050005@oracle.com> References: <4F3A7B45.7020106@oracle.com> <4F3B70D8.5090008@oracle.com> <4F3BB78C.4050005@oracle.com> Message-ID: <4F3BCCF9.9070808@oracle.com> Hi all, Thanks to John and Bengt for the super prompt code reviews! The latest webrev is here: http://cr.openjdk.java.net/~tonyp/7132029/webrev.1/webrev.all/ The changes based on John's comments are here: http://cr.openjdk.java.net/~tonyp/7132029/webrev.1/webrev.1.G1ContMixedJohn/ The changes based on Bengt's comments are here: http://cr.openjdk.java.net/~tonyp/7132029/webrev.1/webrev.2.G1ContMixedBengt/ Bengt, Quick follow-up on the duplicated ergo messages... I simplified the code a bit and now next_gc_should_be_mixed() generates all the ergo messages with the correct action string in each case. Before, the messages looked like this: 4.046: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: appropriate old regions available, phase: end of young GC, remaining old regions: 15 regions, reclaimable: 9791544 bytes (29.18 %), threshold: 1.00 %] 4.046: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: appropriate old regions available] 22M->17M(32M), 0.0309070 secs] ... 4.204: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: appropriate old regions available, phase: end of mixed GC, remaining old regions: 11 regions, reclaimable: 5725080 bytes (17.06 %), threshold: 1.00 %] 4.204: [G1Ergonomics (Mixed GCs) do not end mixed GCs, reason: appropriate old regions available] 22M->14M(32M), 0.0369350 secs] ... 4.597: [G1Ergonomics (Mixed GCs) next GC should not be mixed, reason: reclaimable percentage lower than threshold, phase: end of mixed GC, remaining old regions: 3 regions, reclaimable: 328208 bytes (0.98 %), threshold: 1.00 %] 4.597: [G1Ergonomics (Mixed GCs) end mixed GCs, reason: appropriate old regions not available] 17M->10M(32M), 0.0523420 secs] Now, they look like this (I also changed the output a bit, I didn't like the negative "do not end mixed GCs" if in the case where we carried on doing mixed GCs; and I replaced "appropriate" with "candidate"): 4.131: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 13 regions, reclaimable: 9528680 bytes (28.40 %), threshold: 1.00 %] ... 4.348: [G1Ergonomics (Mixed GCs) continue mixed GCs, reason: candidate old regions available, candidate old regions: 9 regions, reclaimable: 5463560 bytes (16.28 %), threshold: 1.00 %] 23M->15M(32M), 0.0320210 secs] ... 4.781: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage lower than threshold, candidate old regions: 1 regions, reclaimable: 52464 bytes (0.16 %), threshold: 1.00 %] I had to do a minor change in the ergo output framework to allow the action string to be a variable instead of a hard-coded string, but it was pretty pretty trivial. Thanks for the suggestion to simplify this. Tony On 02/15/2012 08:47 AM, Tony Printezis wrote: > Bengt, > > Thanks for looking at this at such short notice! Inline. > > On 02/15/2012 03:46 AM, Bengt Rutisson wrote: >> >> Hi Tony, >> >> I really like this cleanup! Thanks for fixing it. >> >> Some comments: >> >> collectionSetChooser.hpp: >> >> _numMarkedRegions is kind of a confusing name to me. It does not >> contain all the marked regions. > > Well, I left it as it was. And it's also not called > _numAllMarkedRegions. :-) How about I just call it _length (and > _curMarkedIndex -> _curr_index)? > >> It contains all the old regions that we would like to include in the >> collection set. How about _num_selected_regions or even >> _num_selected_old_regions? >> >> I think the remove(HeapRegion* hr) method is kind of strange. I >> understand the need for peek() from finalize_cset(), but I think it >> is strange that the remove() dependes on the code first calling >> peek(). I'd prefer if we could make this more iterator style or at >> least change remove() to someting like pop() that will return the >> next HeapRegion instead of taking it as a parameter. > > Well, peek() and remove() are only called from the loop in > finalize_cset(), so they are tailored for that. I originally had > remove() with no parameters that just removed the current region. I > then thought of passing the region as a parameter mainly to do sanity > testing (i.e., the region that it's being removed is the one we think > it should be removed). And I then realized that, given we already have > the region, there's no point in actually re-reading it from the array. > Si we . I could generalize remove() to accept hr optionally, but given > that we only use it when we know what the region to be removed is, I > don't see the point. Also, I'm not sure that using HeapRegion* pop() > is appropriate either, given that the caller doesn't need to be given > the region that just got removed (it already knows which one it is). > > Also note that the peek() / remove() pattern is similar to the > ListIterator class in Java which has a E next() (equivalent to peek()) > and void remove(). I just added extra information to the remove() > method. (What I'm trying to say is: there's precedence to such a > pattern.) > >> >> collectionSetChooser.cpp: >> >> Why is the method CollectionSetChooser::updateAfterFullCollection() >> needed? Can't G1CollectorPolicy::record_full_collection_end() do >> _collectionSetChooser->clearMarkedHeapRegions() just like >> G1CollectorPolicy::record_concurrent_mark_cleanup_end() does? > > I'm OK either way. Maybe we used to do more in > updateAfterFullCollection() once upon the time but we don't do any > more. I'll remove it and replace it with a direct call to > clearMarkedHeapRegions() as you suggested. > >> g1_globals.hpp: >> >> It seems to me that at least the G1MaxMixedGCNum and the >> G1OldCSetRegionThresholdPercent can be things that end users might >> need to tweak until we have the heuristics more thoroughly tested >> out. Would it be ok to make them available in product builds? Maybe >> as experiemental flags? > > Actually, it might be helpful to expose all four develop flags I added > to the user so that they can control different aspects of the heuristics: > > a) G1OldCSetRegionLiveThresholdPercent and > G1OldReclaimableThresholdPercent: control how much free space to > "sacrifice" in order to decrease mixed GC times (BTW, it'd be nice if > we could somehow combine these two.) > > b) G1MaxMixedGCNum: control how promptly G1 will collect the candidate > old regions: more promptly -> more free space is made available > quicker, less promptly -> each mixed GC might be shorter. > > c) G1OldCSetRegionThresholdPercent: control how aggressive G1 will be > in collecting old regions during each mixed GC: more aggressive -> > more free space is made available quicker, less promptly -> each mixed > GC might be shorter. > > (come to think about it, maybe we should think of combining the last > two too!) > > But before we expose these we need to a) get a better understanding of > what effect each has on G1's performance and b) find better names for > them. :-) (I didn't try very hard, as I assumed that they will be > develop parameters.) > >> g1CollectorPolicy.cpp: >> >> if (next_gc_should_be_mixed("end of young GC")) { >> ergo_verbose0(ErgoMixedGCs, >> "start mixed GCs", >> ergo_format_reason("appropriate old regions >> available")); >> set_gcs_are_young(false); >> } else { >> ergo_verbose0(ErgoMixedGCs, >> "do not start mixed GCs", >> ergo_format_reason("appropriate old regions >> available")); >> } >> >> I think the ergo_verbose message in the else case at lines 1490-1492 >> should say "appropriate old regions not available", right? > > Correct, thanks. John also caught that. > >> We log the ergo decisions in next_gc_should_be_mixed(). Will it not >> be duplicate information to log it in >> G1CollectorPolicy::record_collection_pause_end() as well? > > That's a good point. This is what the output looks like right now: > > 3.708: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: > appropriate old regions available, phase: end of young GC, remaining > old regions: 16 regions, reclaimable: 9803640 bytes (29.22 %), > threshold: 1.00 %] > 3.708: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: appropriate > old regions available] > 23M->18M(32M), 0.0411940 secs] > > ... > > 3.938: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: > appropriate old regions available, phase: end of mixed GC, remaining > old regions: 12 regions, reclaimable: 5823976 bytes (17.36 %), > threshold: 1.00 %] > 3.938: [G1Ergonomics (Mixed GCs) do not end mixed GCs, reason: > appropriate old regions available] > 23M->15M(32M), 0.0322850 secs] > > I'll see how easy will be to parametarize next_gc_should_be_mixed() > with the "do" / "do not" action strings (instead of the phase_str). > > I'll send out a new webrev in a bit. > > Tony > >> Bengt >> >> >> On 2012-02-14 16:18, Tony Printezis wrote: >>> Hi all, >>> >>> I'd like a couple of (quick please!) code reviews for this change: >>> >>> http://cr.openjdk.java.net/~tonyp/7132029/webrev.0/ >>> >>> The policy that was choosing old regions for collection during mixed >>> GCs was buggy and it could exhibit many strange behaviors, one of >>> which was to go into mixed GC mode, do "mixed GCs" (which they did >>> not actually collect any old regions), and not get out of it for a >>> while while preventing subsequent marking cycles not to start. This >>> frequently caused evac failures and Full GCs. >>> >>> The logic on which old regions to add to the CSet was spread to many >>> places. I simplified that and put it mainly in the loop in the >>> finalize_cset() method (renamed from choose_collection_set(), >>> "finalize" is more descriptive on what the method does). I think the >>> new version is easier to follow. >>> >>> Description of the changes: >>> >>> * I have introduced min and max number of old regions to be added to >>> the CSet of each mixed GC. Max number is calculated as a percentage >>> over the heap size (default: 10% - thanks to Jesper for suggesting >>> to use a heap percentage for this) and ensures that collections will >>> not get super long. Min number is calculated based on a desired >>> mixed GC num after a marking cycle (default: 4) and ensures that >>> each mixed GC will make some progress in collecting old regions (so >>> that the candidate old regions are collected in a timely fashion). >>> >>> * We now don't add any regions with live percentage over a threshold >>> (default: 95%) to the CSet chooser and we do not consider them for >>> collection. >>> >>> * I stopped using the cache in the CSet chooser class (it was used >>> to resort regions according to their latest GC efficiency), since >>> it's not necessary any more: we'll now go through all the candidate >>> old regions in the CSet chooser class and we don't have a heuristic >>> of when to stop mixed GCs based on GC efficiency. >>> >>> * I introduced the notion of "reclaimable bytes" on HeapRegions, >>> which not only includes the predicted garbage bytes on each region, >>> but also the unused space in the area [top,end) which will also be >>> reclaimed. The CSet chooser class now keeps track of the total >>> reclaimable bytes of all the regions that it tracks. If that falls >>> under a certain threshold (default: 1% of the heap) we stop doing >>> mixed GCs as we'll reclaim very little out of the remaining >>> candidate old regions. >>> >>> * I eliminated the case where a mixed GC starts and picks no old >>> regions to collect (I hope!). Now the information on the CSet >>> chooser (remaining region num / remaining reclaimable bytes) can >>> tell us whether we want to do more mixed GCs or not. If we do, it's >>> guaranteed that there will be old regions to collect. Because of >>> that, I removed the _should_revert_to_young_gcs flag as it's not >>> needed any more. It was used so that the CSet choice code could flag >>> that we should stop doing mixed GCs at the end of the GC. Now, we >>> can decide that by just looking at the information on the CSet >>> chooser (the heuristic is encapsulated in the >>> next_gc_should_be_mixed()). >>> >>> * I also changed the policy in the case where a fixed young gen is >>> used. Before, we were a bit arbitrary: during mixed GCs we'd cut the >>> young gen size in half and fill up the rest with old regions. I >>> thought that trying to re-use the "desired mixed GC number" >>> heuristic for this made sense. So, I now add the min number of old >>> regions to each mixed GC (as long as we don't go over the max). I >>> think this is a more reasonable and less arbitrary heuristic to what >>> we had before and it's more consistent with the non-fixed young gen >>> policy. I didn't know whether I should decrease the young gen size >>> for each mixed GC, like how we did before, and by how much. So, I >>> now leave it unchanged (the user decided they want a fixed young >>> gen, they will now always get it!). >>> >>> * Updated all related ergo output to print the new information. >>> >>> Like the marking changes, this change leaves a fair amount of unused >>> code that we can remove. I had to draw the line somewhere on how >>> much I should remove now and how much I should leave for later. I >>> opened a new CR for the remaining cleanup: >>> >>> 7145441: G1: collection set chooser-related cleanup >>> >>> Many thanks to Charlie for doing some last-minute performance >>> testing with my workspace. He was the one who discovered the problem >>> with the never-ending mixed GCs and this fix eliminated the problem. >>> Correctness-testing-wise, I've run overnight with the GC test suite. >>> >>> Thanks, >>> >>> Tony >>> >>> >> From tony.printezis at oracle.com Wed Feb 15 10:36:56 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 15 Feb 2012 13:36:56 -0500 Subject: CRR (M): 7132029: G1: mixed GC phase lasts for longer than it should In-Reply-To: <4F3BC123.5070405@oracle.com> References: <4F3A7B45.7020106@oracle.com> <4F3B70D8.5090008@oracle.com> <4F3BB78C.4050005@oracle.com> <4F3BC123.5070405@oracle.com> Message-ID: <4F3BFB48.80200@oracle.com> Bengt, (We discussed this over the phone, but for the record) move_to_next() is not quite descriptive either, give that the region is actually removed. I left the remove() method as is but renamed it remove_and_move_to_next() as a compromise. Tony On 02/15/2012 09:28 AM, Bengt Rutisson wrote: > > Tony, > > Very short reply inline. > > On 2012-02-15 14:47, Tony Printezis wrote: >> Bengt, >> >> Thanks for looking at this at such short notice! Inline. >> >> On 02/15/2012 03:46 AM, Bengt Rutisson wrote: >>> >>> Hi Tony, >>> >>> I really like this cleanup! Thanks for fixing it. >>> >>> Some comments: >>> >>> collectionSetChooser.hpp: >>> >>> _numMarkedRegions is kind of a confusing name to me. It does not >>> contain all the marked regions. >> >> Well, I left it as it was. And it's also not called >> _numAllMarkedRegions. :-) How about I just call it _length (and >> _curMarkedIndex -> _curr_index)? > > OK. > >> >>> It contains all the old regions that we would like to include in the >>> collection set. How about _num_selected_regions or even >>> _num_selected_old_regions? >>> >>> I think the remove(HeapRegion* hr) method is kind of strange. I >>> understand the need for peek() from finalize_cset(), but I think it >>> is strange that the remove() dependes on the code first calling >>> peek(). I'd prefer if we could make this more iterator style or at >>> least change remove() to someting like pop() that will return the >>> next HeapRegion instead of taking it as a parameter. >> >> Well, peek() and remove() are only called from the loop in >> finalize_cset(), so they are tailored for that. I originally had >> remove() with no parameters that just removed the current region. I >> then thought of passing the region as a parameter mainly to do sanity >> testing (i.e., the region that it's being removed is the one we think >> it should be removed). And I then realized that, given we already >> have the region, there's no point in actually re-reading it from the >> array. Si we . I could generalize remove() to accept hr optionally, >> but given that we only use it when we know what the region to be >> removed is, I don't see the point. Also, I'm not sure that using >> HeapRegion* pop() is appropriate either, given that the caller >> doesn't need to be given the region that just got removed (it already >> knows which one it is). >> >> Also note that the peek() / remove() pattern is similar to the >> ListIterator class in Java which has a E next() (equivalent to >> peek()) and void remove(). I just added extra information to the >> remove() method. (What I'm trying to say is: there's precedence to >> such a pattern.) > > I'm sorry. I still don't like the remove() method. Can we inline the > "_remainingReclaimableBytes -= hr->reclaimable_bytes();" where we now > call remove() and then call remove() something like move_to_next() > without any HeapRegion at all? Not sure that this was a good > suggestion... > > Bengt > >> >>> >>> collectionSetChooser.cpp: >>> >>> Why is the method CollectionSetChooser::updateAfterFullCollection() >>> needed? Can't G1CollectorPolicy::record_full_collection_end() do >>> _collectionSetChooser->clearMarkedHeapRegions() just like >>> G1CollectorPolicy::record_concurrent_mark_cleanup_end() does? >> >> I'm OK either way. Maybe we used to do more in >> updateAfterFullCollection() once upon the time but we don't do any >> more. I'll remove it and replace it with a direct call to >> clearMarkedHeapRegions() as you suggested. >> >>> g1_globals.hpp: >>> >>> It seems to me that at least the G1MaxMixedGCNum and the >>> G1OldCSetRegionThresholdPercent can be things that end users might >>> need to tweak until we have the heuristics more thoroughly tested >>> out. Would it be ok to make them available in product builds? Maybe >>> as experiemental flags? >> >> Actually, it might be helpful to expose all four develop flags I >> added to the user so that they can control different aspects of the >> heuristics: >> >> a) G1OldCSetRegionLiveThresholdPercent and >> G1OldReclaimableThresholdPercent: control how much free space to >> "sacrifice" in order to decrease mixed GC times (BTW, it'd be nice if >> we could somehow combine these two.) >> >> b) G1MaxMixedGCNum: control how promptly G1 will collect the >> candidate old regions: more promptly -> more free space is made >> available quicker, less promptly -> each mixed GC might be shorter. >> >> c) G1OldCSetRegionThresholdPercent: control how aggressive G1 will be >> in collecting old regions during each mixed GC: more aggressive -> >> more free space is made available quicker, less promptly -> each >> mixed GC might be shorter. >> >> (come to think about it, maybe we should think of combining the last >> two too!) >> >> But before we expose these we need to a) get a better understanding >> of what effect each has on G1's performance and b) find better names >> for them. :-) (I didn't try very hard, as I assumed that they will be >> develop parameters.) >> >>> g1CollectorPolicy.cpp: >>> >>> if (next_gc_should_be_mixed("end of young GC")) { >>> ergo_verbose0(ErgoMixedGCs, >>> "start mixed GCs", >>> ergo_format_reason("appropriate old regions >>> available")); >>> set_gcs_are_young(false); >>> } else { >>> ergo_verbose0(ErgoMixedGCs, >>> "do not start mixed GCs", >>> ergo_format_reason("appropriate old regions >>> available")); >>> } >>> >>> I think the ergo_verbose message in the else case at lines 1490-1492 >>> should say "appropriate old regions not available", right? >> >> Correct, thanks. John also caught that. >> >>> We log the ergo decisions in next_gc_should_be_mixed(). Will it not >>> be duplicate information to log it in >>> G1CollectorPolicy::record_collection_pause_end() as well? >> >> That's a good point. This is what the output looks like right now: >> >> 3.708: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: >> appropriate old regions available, phase: end of young GC, remaining >> old regions: 16 regions, reclaimable: 9803640 bytes (29.22 %), >> threshold: 1.00 %] >> 3.708: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: >> appropriate old regions available] >> 23M->18M(32M), 0.0411940 secs] >> >> ... >> >> 3.938: [G1Ergonomics (Mixed GCs) next GC should be mixed, reason: >> appropriate old regions available, phase: end of mixed GC, remaining >> old regions: 12 regions, reclaimable: 5823976 bytes (17.36 %), >> threshold: 1.00 %] >> 3.938: [G1Ergonomics (Mixed GCs) do not end mixed GCs, reason: >> appropriate old regions available] >> 23M->15M(32M), 0.0322850 secs] >> >> I'll see how easy will be to parametarize next_gc_should_be_mixed() >> with the "do" / "do not" action strings (instead of the phase_str). >> >> I'll send out a new webrev in a bit. >> >> Tony >> >>> Bengt >>> >>> >>> On 2012-02-14 16:18, Tony Printezis wrote: >>>> Hi all, >>>> >>>> I'd like a couple of (quick please!) code reviews for this change: >>>> >>>> http://cr.openjdk.java.net/~tonyp/7132029/webrev.0/ >>>> >>>> The policy that was choosing old regions for collection during >>>> mixed GCs was buggy and it could exhibit many strange behaviors, >>>> one of which was to go into mixed GC mode, do "mixed GCs" (which >>>> they did not actually collect any old regions), and not get out of >>>> it for a while while preventing subsequent marking cycles not to >>>> start. This frequently caused evac failures and Full GCs. >>>> >>>> The logic on which old regions to add to the CSet was spread to >>>> many places. I simplified that and put it mainly in the loop in the >>>> finalize_cset() method (renamed from choose_collection_set(), >>>> "finalize" is more descriptive on what the method does). I think >>>> the new version is easier to follow. >>>> >>>> Description of the changes: >>>> >>>> * I have introduced min and max number of old regions to be added >>>> to the CSet of each mixed GC. Max number is calculated as a >>>> percentage over the heap size (default: 10% - thanks to Jesper for >>>> suggesting to use a heap percentage for this) and ensures that >>>> collections will not get super long. Min number is calculated based >>>> on a desired mixed GC num after a marking cycle (default: 4) and >>>> ensures that each mixed GC will make some progress in collecting >>>> old regions (so that the candidate old regions are collected in a >>>> timely fashion). >>>> >>>> * We now don't add any regions with live percentage over a >>>> threshold (default: 95%) to the CSet chooser and we do not consider >>>> them for collection. >>>> >>>> * I stopped using the cache in the CSet chooser class (it was used >>>> to resort regions according to their latest GC efficiency), since >>>> it's not necessary any more: we'll now go through all the candidate >>>> old regions in the CSet chooser class and we don't have a heuristic >>>> of when to stop mixed GCs based on GC efficiency. >>>> >>>> * I introduced the notion of "reclaimable bytes" on HeapRegions, >>>> which not only includes the predicted garbage bytes on each region, >>>> but also the unused space in the area [top,end) which will also be >>>> reclaimed. The CSet chooser class now keeps track of the total >>>> reclaimable bytes of all the regions that it tracks. If that falls >>>> under a certain threshold (default: 1% of the heap) we stop doing >>>> mixed GCs as we'll reclaim very little out of the remaining >>>> candidate old regions. >>>> >>>> * I eliminated the case where a mixed GC starts and picks no old >>>> regions to collect (I hope!). Now the information on the CSet >>>> chooser (remaining region num / remaining reclaimable bytes) can >>>> tell us whether we want to do more mixed GCs or not. If we do, it's >>>> guaranteed that there will be old regions to collect. Because of >>>> that, I removed the _should_revert_to_young_gcs flag as it's not >>>> needed any more. It was used so that the CSet choice code could >>>> flag that we should stop doing mixed GCs at the end of the GC. Now, >>>> we can decide that by just looking at the information on the CSet >>>> chooser (the heuristic is encapsulated in the >>>> next_gc_should_be_mixed()). >>>> >>>> * I also changed the policy in the case where a fixed young gen is >>>> used. Before, we were a bit arbitrary: during mixed GCs we'd cut >>>> the young gen size in half and fill up the rest with old regions. I >>>> thought that trying to re-use the "desired mixed GC number" >>>> heuristic for this made sense. So, I now add the min number of old >>>> regions to each mixed GC (as long as we don't go over the max). I >>>> think this is a more reasonable and less arbitrary heuristic to >>>> what we had before and it's more consistent with the non-fixed >>>> young gen policy. I didn't know whether I should decrease the young >>>> gen size for each mixed GC, like how we did before, and by how >>>> much. So, I now leave it unchanged (the user decided they want a >>>> fixed young gen, they will now always get it!). >>>> >>>> * Updated all related ergo output to print the new information. >>>> >>>> Like the marking changes, this change leaves a fair amount of >>>> unused code that we can remove. I had to draw the line somewhere on >>>> how much I should remove now and how much I should leave for later. >>>> I opened a new CR for the remaining cleanup: >>>> >>>> 7145441: G1: collection set chooser-related cleanup >>>> >>>> Many thanks to Charlie for doing some last-minute performance >>>> testing with my workspace. He was the one who discovered the >>>> problem with the never-ending mixed GCs and this fix eliminated the >>>> problem. Correctness-testing-wise, I've run overnight with the GC >>>> test suite. >>>> >>>> Thanks, >>>> >>>> Tony >>>> >>>> >>> > From John.Coomes at oracle.com Wed Feb 15 12:45:01 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 15 Feb 2012 12:45:01 -0800 Subject: review request (m): 6330863 InfiniteList.java intermittent timeout In-Reply-To: <4F3B99C1.60503@oracle.com> References: <20282.45391.913824.703384@oracle.com> <4F3B99C1.60503@oracle.com> Message-ID: <20284.6477.827923.864479@oracle.com> Stefan Karlsson (stefan.karlsson at oracle.com) wrote: > Hi John, > > This looks good, but I have a couple of style change suggestions. See > inlined: > > On 02/14/2012 08:09 PM, John Coomes wrote: > > I'd appreciate reviews of these changes to fix a corner-case that > > can cause test timeouts with parallel old gc. > > > > The review is in two parts; the first part is a prereq that's easily > > separated so it's in a separate webrev to make reviews of the real fix > > a bit easier. > > > > 1) change the PS invoke methods to return an indicator of whether a gc > > was done: > > > > http://cr.openjdk.java.net/~jcoomes/6330863-invoke-return-val/ > > http://cr.openjdk.java.net/~jcoomes/6330863-invoke-return-val/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp.frames.html > > 229 - bool scavenge_was_done = PSScavenge::invoke_no_policy(); > 229 + const bool need_full_gc = !PSScavenge::invoke_no_policy() || > 230 + policy->should_full_GC(heap->old_gen()->free_in_bytes()); > 231 + bool did_full_gc = false; > > IMHO, inlining the invoke_no_policy call here makes it harder to read. > Would you mind keeping scavenge_was_done and use it on line 229? Not at all, I'll do that. > 223-250 ... > > I think it would be good for readability to extract counter update code > out of the full GC calling code. For example: > if (UsePerfData) { > PSGCAdaptivePolicyCounters* const counters = heap->gc_policy_counters(); > if (need_full_gc) { > counters->update_full_follows_scavenge(full_follows_scavenge); > } else { > counters->update_full_follows_scavenge(0); > } > } > > if (need_full_gc) { > GCCauseSetter gccs(heap, GCCause::_adaptive_size_policy); > CollectorPolicy* cp = heap->collector_policy(); > const bool clear_all_softrefs = cp->should_clear_all_soft_refs(); > > if (UseParallelOldGC) { > did_full_gc = PSParallelCompact::invoke_no_policy(clear_all_softrefs); > } else { > did_full_gc = PSMarkSweep::invoke_no_policy(clear_all_softrefs); > } > } I like that better too, so I'll do it. > > 2) adjust the allocation policy: > > > > http://cr.openjdk.java.net/~jcoomes/6330863-death-march/ > > http://cr.openjdk.java.net/~jcoomes/6330863-death-march/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp.frames.html > > 421 if (result != NULL) return result; > and > 425 if (result != NULL) return result; > > Could you keep the return statements on a separate line? Sure, easy enough. Thanks for the review! -John From tony.printezis at oracle.com Wed Feb 15 14:20:17 2012 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Wed, 15 Feb 2012 22:20:17 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7132029: G1: mixed GC phase lasts for longer than it should Message-ID: <20120215222022.7496947503@hg.openjdk.java.net> Changeset: a9647476d1a4 Author: tonyp Date: 2012-02-15 13:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a9647476d1a4 7132029: G1: mixed GC phase lasts for longer than it should Summary: Revamp of the mechanism that chooses old regions for inclusion in the CSet. It simplifies the code and introduces min and max bounds on the number of old regions added to the CSet at each mixed GC to avoid pathological cases. It also ensures that when we do a mixed GC we'll always find old regions to add to the CSet (i.e., it eliminates the case where a mixed GC will collect no old regions which can happen today). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.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/g1ErgoVerbose.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 From john.coomes at oracle.com Thu Feb 16 16:46:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 00:46:06 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 2 new changesets Message-ID: <20120217004612.595144752E@hg.openjdk.java.net> Changeset: ab4422d0ed59 Author: jcoomes Date: 2012-02-16 13:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ab4422d0ed59 7146343: PS invoke methods should indicate the type of gc done Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp Changeset: 23c0eb012d6f Author: jcoomes Date: 2012-02-16 13:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/23c0eb012d6f 6330863: vm/gc/InfiniteList.java fails intermittently due to timeout Summary: in some cases, allocate from the old gen before doing a full gc Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp From john.coomes at oracle.com Thu Feb 16 20:54:18 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:54:18 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b26 for changeset 2accafff224a Message-ID: <20120217045418.50AD94754E@hg.openjdk.java.net> Changeset: 1533dfab9903 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/1533dfab9903 Added tag jdk8-b26 for changeset 2accafff224a ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:54:25 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:54:25 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b26 for changeset 79f709a099f4 Message-ID: <20120217045427.660464754F@hg.openjdk.java.net> Changeset: 4fffe75e4edd Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/4fffe75e4edd Added tag jdk8-b26 for changeset 79f709a099f4 ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:54:36 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:54:36 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b26 for changeset dbb7283c197b Message-ID: <20120217045436.AE43047550@hg.openjdk.java.net> Changeset: 80c47eb83d24 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/80c47eb83d24 Added tag jdk8-b26 for changeset dbb7283c197b ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:54:45 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:54:45 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b26 for changeset 3518639eab6c Message-ID: <20120217045445.4B92847551@hg.openjdk.java.net> Changeset: 329ace7198ac Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/329ace7198ac Added tag jdk8-b26 for changeset 3518639eab6c ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:54:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:54:54 +0000 Subject: hg: hsx/hotspot-gc/jdk: Added tag jdk8-b26 for changeset 5aca406e87cb Message-ID: <20120217045532.13E9B47552@hg.openjdk.java.net> Changeset: 4196fc971f65 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4196fc971f65 Added tag jdk8-b26 for changeset 5aca406e87cb ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:56:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:56:49 +0000 Subject: hg: hsx/hotspot-gc/langtools: Added tag jdk8-b26 for changeset b556aa8a99c3 Message-ID: <20120217045656.53A4747553@hg.openjdk.java.net> Changeset: fba3cbee0fa3 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/fba3cbee0fa3 Added tag jdk8-b26 for changeset b556aa8a99c3 ! .hgtags From john.coomes at oracle.com Fri Feb 17 23:58:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 18 Feb 2012 07:58:35 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 62 new changesets Message-ID: <20120218080040.A9E894757C@hg.openjdk.java.net> Changeset: aaceb8ddf2e2 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aaceb8ddf2e2 Added tag jdk8-b25 for changeset 9ad8feb5afbd ! .hgtags Changeset: 869be5c8882e Author: phh Date: 2012-02-03 17:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/869be5c8882e 7142586: Cannot build on Solaris 11 due to use of ia_nice Summary: Delete the single use of ia_nice in os_solaris.cpp Reviewed-by: kamg, kvn ! src/os/solaris/vm/os_solaris.cpp Changeset: c77d473e71f7 Author: ohrstrom Date: 2012-01-31 13:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c77d473e71f7 7132779: build-infra merge: Enable ccache to work for most developer builds. Summary: When a build number is not specified, the JRE_RELEASE_VERSION define contains a date and timestamp. Thus ccache cannot cache the object files for longer than a minute since the define is passed to the compilation of all source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and adds a function jre_release_version() to Abstract_VM_Version. This allows all other source files to be ccached. Reviewed-by: ohair, rottenha Contributed-by: fredrik.ohrstrom at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make Changeset: ea677dbdd883 Author: fparain Date: 2012-02-07 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ea677dbdd883 Merge Changeset: 5e9fba4e8718 Author: kvn Date: 2012-02-07 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5e9fba4e8718 7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp implementation as __clang__ (as is the case for os::current_stack_pointer). Reviewed-by: twisti, never, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: b9bc6cae88f2 Author: kvn Date: 2012-02-07 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b9bc6cae88f2 7143491: G1 C2 CTW: assert(p2x->outcnt() == 2) failed: expects 2 users: Xor and URShift nodes Summary: Adjust the assert and code in eliminate_card_mark() method for case when stored value is NULL. Reviewed-by: iveresov, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp Changeset: c742b0b47fe5 Author: roland Date: 2012-02-08 09:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c742b0b47fe5 7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, Thread*)+0x3c Summary: unaligned stack in throw_NullPointerException_at_call_entry(). Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2f985b6ce7ff Author: jrose Date: 2012-02-09 18:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2f985b6ce7ff Merge Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f3fa16bd7159 Merge Changeset: b7b8b6d2f97d Author: bpittore Date: 2012-02-06 10:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b7b8b6d2f97d Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f174909614bd Author: bpittore Date: 2012-02-10 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f174909614bd Merge ! src/share/vm/opto/library_call.cpp Changeset: d71e662fe037 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d71e662fe037 Merge Changeset: fd3060701216 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fd3060701216 Added tag hs23-b15 for changeset d71e662fe037 ! .hgtags Changeset: 087daaec688d Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/087daaec688d Added tag jdk8-b26 for changeset fd3060701216 ! .hgtags Changeset: 094138495da4 Author: amurillo Date: 2012-02-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/094138495da4 7144322: new hotspot build - hs23-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 77a488cd4af2 Author: dlong Date: 2012-02-15 00:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/77a488cd4af2 7140866: assert(covered) failed: Card for end of new region not committed Summary: resize covered region only after successfully mapping shared archive Reviewed-by: brutisso, ysr Contributed-by: dean.long at oracle.com ! src/share/vm/memory/compactingPermGenGen.cpp Changeset: f9961b6498f9 Author: bpittore Date: 2012-02-15 16:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f9961b6498f9 Merge Changeset: be398bba40e9 Author: stefank Date: 2012-02-17 13:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/be398bba40e9 Merge Changeset: 1b0e0f8be510 Author: minqi Date: 2012-02-09 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1b0e0f8be510 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: dholmes, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/utilities/preserveException.cpp Changeset: db006a85bf91 Author: zgu Date: 2012-02-09 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db006a85bf91 7141259: Native stack is missing in hs_err Summary: Code cleanup and creating a private decoder for error handler, since it can be triggered from in signal handler, where no lock can be taken Reviewed-by: dholmes, kamg, acorn, coleenp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/vmError.hpp Changeset: ea527c5cde03 Author: zgu Date: 2012-02-09 07:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ea527c5cde03 Merge Changeset: 54d3535a6dd3 Author: poonam Date: 2012-02-12 19:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/54d3535a6dd3 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Summary: Added Large File Support by compiling libsaproc.so with -D_FILE_OFFSET_BITS=64, and a small change with which SA should first load libraries from the path specified with SA_ALTROOT. Reviewed-by: dholmes, kevinw, dcubed, minqi ! agent/src/os/linux/Makefile ! agent/src/os/linux/libproc_impl.c ! make/linux/makefiles/saproc.make Changeset: 1bb2838e2fc1 Author: fparain Date: 2012-02-13 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1bb2838e2fc1 Merge Changeset: 849412a95e45 Author: coleenp Date: 2012-02-13 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/849412a95e45 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh ! src/cpu/x86/vm/globals_x86.hpp Changeset: 1891640ca63f Author: fparain Date: 2012-02-14 06:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1891640ca63f 7143760: Memory leak in GarbageCollectionNotifications Reviewed-by: dholmes, dcubed, kamg ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp Changeset: a9831b955a0a Author: kamg Date: 2012-02-13 14:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a9831b955a0a 7069991: Setup make/jprt.properties files for jdk8 Summary: Change default release value to jdk8 (but overrideable) Reviewed-by: phh, jcoomes, dholmes, ohair ! make/jprt.properties Changeset: a9ac4910e7f2 Author: kamg Date: 2012-02-14 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a9ac4910e7f2 Merge Changeset: 28d91e43ab6d Author: coleenp Date: 2012-02-14 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/28d91e43ab6d 7145587: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV (sparc version) Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh, dcubed, kamg, dsamersoff ! src/cpu/sparc/vm/globals_sparc.hpp Changeset: cf772dff4bfd Author: coleenp Date: 2012-02-14 18:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cf772dff4bfd Merge Changeset: b8a4e1d372a0 Author: kamg Date: 2012-02-14 20:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b8a4e1d372a0 7145589: First JSDT provider creation fails Summary: 0 is a successful return from an ioctl() call Reviewed-by: dcubed, phh, dsamersoff ! src/share/vm/runtime/dtraceJSDT.cpp Changeset: 91a81502a27d Author: kamg Date: 2012-02-15 00:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/91a81502a27d Merge Changeset: 2b150750d53d Author: sspitsyn Date: 2012-02-14 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2b150750d53d 7130993: nsk/jdi/ReferenceType/instances/instances004 fails with JFR: assert(ServiceUtil::visible_oop(obj)) Summary: Skip reporting invisible refs in iterate_over_object to avoid assert(ServiceUtil::visible_oop(obj)) Reviewed-by: dcubed, mgronlun, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: cd239a88b90c Author: minqi Date: 2012-02-14 20:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cd239a88b90c Merge Changeset: 64fc5ac1b770 Author: minqi Date: 2012-02-14 23:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/64fc5ac1b770 Merge Changeset: f1cb6f9cfe21 Author: fparain Date: 2012-02-15 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f1cb6f9cfe21 7145243: Need additional specializations for argument parsing framework Reviewed-by: acorn, fparain Contributed-by: nils.loodin at oracle.com ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp Changeset: 4a24c4f648bd Author: phh Date: 2012-02-16 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4a24c4f648bd 7142113: Add Ivy Bridge to the known Intel x86 cpu families Summary: In vm_version_x86.hpp, add and use CPU_MODEL_IVYBRIDGE_EP, and restrict is_intel_tsc_synced_at_init() to EP models. Reviewed-by: kvn, acorn ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 7df3125953cb Author: coleenp Date: 2012-02-16 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7df3125953cb 7146354: Re-enable Compressed OOPs after 7118647 is resolved Summary: Relax the assertion to simply check for COOP mode rather than an exact address. Reviewed-by: coleenp, kvn, phh, dcubed Contributed-by: james.melvin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: df4927a3b82e Author: coleenp Date: 2012-02-16 17:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/df4927a3b82e Merge Changeset: d3384450b649 Author: fparain Date: 2012-02-17 06:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d3384450b649 Merge Changeset: 73df3733f2eb Author: kvn Date: 2012-02-10 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/73df3733f2eb 7129284: +DoEscapeAnalysis regression w/ early build of 7u4 (HotSpot 23) on Linux Summary: Removed code which tried to create edges from fields of destination objects of arraycopy to fields of source objects. Added 30 sec time limit for EA graph construction. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: de34c646c3f7 Author: kvn Date: 2012-02-10 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/de34c646c3f7 7140985: HSDIS does not handle caller options correctly Summary: Fix typo. Reviewed-by: jrose, kvn Contributed-by: Andrew Haley ! src/share/tools/hsdis/hsdis.c Changeset: 45a1bf98f1bb Author: twisti Date: 2012-02-13 02:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/45a1bf98f1bb 7141329: Strange values of stack_size in -XX:+TraceMethodHandles output Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f09ae3853e3b Author: twisti Date: 2012-02-13 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f09ae3853e3b 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: rbackman, jrose, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/top.make ! make/defs.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make Changeset: b522995d91f0 Author: roland Date: 2012-02-14 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b522995d91f0 7144405: JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found Summary: oop map needs pc stored in frame anchor in StubGenerator::generate_throw_exception() Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 8f4eb44b3b76 Author: never Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8f4eb44b3b76 7143061: nsk/stress/stack/b4525850 crash VM Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp Changeset: 80107dc493db Author: roland Date: 2012-02-15 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/80107dc493db 7126041: jdk7u4 b05 and b06 crash with RubyMine 3.2.4, works well with b04 Summary: Goto that replaces a If mistaken to be a back branch and triggers erroneous OSR compilation. Reviewed-by: never, iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 09d00c18e323 Author: never Date: 2012-02-15 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/09d00c18e323 7145537: minor tweaks to LogEvents Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp Changeset: cfdfbeac0a5b Author: iveresov Date: 2012-02-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cfdfbeac0a5b 7145345: Code cache sweeper must cooperate with safepoints Summary: Safepoint in the sweeper loop in necessary Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 69333a2fbae2 Author: iveresov Date: 2012-02-15 16:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/69333a2fbae2 7142680: default GC affected by jvm path Summary: Removed old tiered code Reviewed-by: never, kvn ! src/share/vm/runtime/arguments.cpp Changeset: fd8114661503 Author: kvn Date: 2012-02-15 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fd8114661503 7125136: SIGILL on linux amd64 in gc/ArrayJuggle/Juggle29 Summary: For C2 moved saving EBP after ESP adjustment. For C1 generated 5 byte nop instruction first if needed. Reviewed-by: never, twisti, azeemj ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/output.cpp Changeset: c7401dcad8bf Author: roland Date: 2012-02-16 09:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c7401dcad8bf 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num Summary: forced exit may destory global objects that are still in use. Reviewed-by: twisti, never, kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: ad3b47344802 Author: never Date: 2012-02-16 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ad3b47344802 7144318: GCLocker assert failure: assert(_needs_gc || SafepointSynchronize::is_at_safepoint( Reviewed-by: kvn, twisti ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp Changeset: 9b8ce46870df Author: kvn Date: 2012-02-16 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9b8ce46870df 7145346: VerifyStackAtCalls is broken Summary: Replace call_epilog() encoding with macroassembler use. Moved duplicated code to x86.ad. Fixed return_addr() definition. Reviewed-by: never ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/opto/chaitin.cpp Changeset: 72c425c46102 Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/72c425c46102 7146729: nightly failure after 7141200: tty is sometimes null during shutdown of main thread Reviewed-by: kvn ! src/share/vm/utilities/events.hpp Changeset: 15085a6eb50c Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/15085a6eb50c Merge ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: f92a171cf007 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f92a171cf007 Merge Changeset: 98cd09d11a21 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/98cd09d11a21 Added tag hs23-b16 for changeset f92a171cf007 ! .hgtags Changeset: 4ab89de75552 Author: amurillo Date: 2012-02-17 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4ab89de75552 7146700: new hotspot build - hs24-b01 Reviewed-by: jcoomes ! make/hotspot_version From alexey.ragozin at gmail.com Tue Feb 21 00:03:50 2012 From: alexey.ragozin at gmail.com (Alexey Ragozin) Date: Tue, 21 Feb 2012 12:03:50 +0400 Subject: Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning Message-ID: Hi, I would like few volunteers to review changes for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ Change summary For large heaps (I was focusing on 8GiB and above) it is common to have long continuous ranges of clean cards. Patch is introducing a short path for skipping ranges of clean cards using word aligned memory access instead of byte aligned. Patch affects serial and CMS collectors. For CMS collector stride size should be increase to see any performance gains (I was using -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=4096) For testing I was mainly using synthetic benchmark randomly modifying hash tables in heap, thus uniformly touching cards across heaps. Average duration of young GC pause were used as KPI. More details about testing can be found at http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html Though article is referring jdk6, my resent tests with trunk jdk7 show no difference. I was also tested patch with real application (Oracle Coherence storage node). With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC pauses roughly in 2 times. Source code of benchmark used in test are available at https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench Main class YoungGCPauseBenchmark Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120221/bb726108/attachment.html From mark.reinhold at oracle.com Tue Feb 21 15:48:24 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 21 Feb 2012 15:48:24 -0800 (PST) Subject: JEP 141: Increase the Client VM's Default Heap Size Message-ID: <20120221234824.93D481637@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/141 - Mark From ysr1729 at gmail.com Tue Feb 21 21:49:48 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 21 Feb 2012 21:49:48 -0800 Subject: changing the memory settings semi-dynamically vs GateKeeper and signing In-Reply-To: References: <0BBF8DCB-597D-4838-BC15-79D9DBB42EF2@tagtraum.com> <8EAA9E23-4C8F-4D75-8278-9D859F226CAE@apple.com> Message-ID: Good points... It's a good idea to cross- post this over to hotspot-gc-dev since it's relevant to "client ergonomics" or current lack thereof.... Sent from my iPhone On Feb 21, 2012, at 20:54, Andrew Thompson wrote: > > On Feb 20, 2012, at 1:00 PM, Mike Swingler wrote: > >> On Feb 20, 2012, at 12:17 AM, Hendrik Schreiber wrote: >> >>> Hi, >>> >>> I already posted this on the Apple java-dev list - Mike S. recommended taking this topic here. >>> >>> Here's (more or less) the post from java-dev: >>> >>>> I guess most of us who ship java applications ship them with explicit memory settings (-Xmx ...) in the Info.plist file. > > > In this whole discussion of passing in command line arguments to .app bundles I do find myself wondering *why* we're doing so. > > Passing -Xmx seems like something we should be trying to eliminate, not support. > > For the sake of argument, let's assume we do not use -Xmx. Right now, GC ergonomics will kick in and do the following > > (From http://www.oracle.com/technetwork/java/ergo5-140223.html#0.0.%20Garbage%20collector,%20heap,%20and%20runtime%20compiler%7Coutline) > > initial heap size of 1/64 of physical memory up to 1Gbyte > > maximum heap size of ? of physical memory up to 1Gbyte > > But why should this be the behavior? Apps written in Objective C don't self limit, so why not make Xmx default to physical RAM size? > > I can give at least a partial answer: because most of the Garbage Collectors available for Java NEVER shrink the heap once it grows. What then ends up happening is a "high water mark" effect. Say you have an application that needs to allocate 1.5GB of memory during startup, but once it is up and running it then only needs 500mb? Well, under most Java GCs today the heap is going to grow to at least 1.5GB and never come down again. Let me be clear; the 1.5 GB heap will have 500mb of data and 1gb of free space; it collects the garbage but it never shrinks (gives memory back to the OS).. > > In fact, as far as I know only the old serial GC ever gives back memory, but that's not the default collector in a 64bit VM. Parallel GC is. One can use the ergonomics goal settings mentioned here: > > http://www.oracle.com/technetwork/java/ergo5-140223.html#1.1.1.Maximum%20pause%20time%20goal%7Coutline > > These influence whether the VM collects or grows the heap, but they have no impact on shrinking the heap under the parallel collector. Don't take my word for it, there's a thread on the hotspot-GC-dev list about this, a patch is proposed but the conversation peters out > > http://markmail.org/message/xalkitas66s3w7pt#query:+page:1+mid:ci5y6rkvdswbwwhs+state:results > > This limitation has a chilling effect as if at anytime an application requires more memory the heap will grow, but when that turns out to be a temporary condition and garbage is collected the heap does not shrink back down again. What person shipping a client-side app would take that risk? > > What I'd like to see is something like > > initial heap size is ?1/64? physical memory > > maximum heap size is equal to physical memory > > With heap shrinking working, one could risk not setting Xmx and letting it be physical RAM size because even if the app temporarily uses this much memory, it'll give back when it calms down. > But since heap shrinking does not work with most GCs, Xmx is here to stay, I fear. From mbien at fh-landshut.de Wed Feb 22 04:28:02 2012 From: mbien at fh-landshut.de (Michael Bien) Date: Wed, 22 Feb 2012 13:28:02 +0100 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <20120221234824.93D481637@eggemoggin.niobe.net> References: <20120221234824.93D481637@eggemoggin.niobe.net> Message-ID: <4F44DF52.3060804@fh-landshut.de> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/141 > > - Mark > additional risks: - JVM may not be able to start - could contribute to the false impression that java requires a lot of memory to run (JVMs usually don't like to give memory back to the OS once its in use) best regards, michael -- http://michael-bien.com/ From jon.masamitsu at oracle.com Wed Feb 22 07:38:26 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 22 Feb 2012 07:38:26 -0800 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F44DF52.3060804@fh-landshut.de> References: <20120221234824.93D481637@eggemoggin.niobe.net> <4F44DF52.3060804@fh-landshut.de> Message-ID: <4F450BF2.3030708@oracle.com> On 2/22/2012 4:28 AM, Michael Bien wrote: > On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/141 >> >> - Mark >> > additional risks: > - JVM may not be able to start Specifically, the JVM tries to reserve enough memory at start up for the heap and fails to initialize if it cannot? Will add it. > - could contribute to the false impression that java requires a lot > of memory to run (JVMs usually don't like to give memory back to the > OS once its in use) Is this an impression the user would get because the JVM would not start up as you note above? The JVM does not necessarily use all the memory it reserves. Thanks. Jon > > best regards, > michael > From vitalyd at gmail.com Wed Feb 22 07:55:22 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Feb 2012 10:55:22 -0500 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F450BF2.3030708@oracle.com> References: <20120221234824.93D481637@eggemoggin.niobe.net> <4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> Message-ID: I think the impression could also be based on virt mem size of the process (I.e. committed + reserved). The failure to start is probably a real concern for OS's without overcommit, especially if multiple java procs are running at the same time. Sent from my phone On Feb 22, 2012 10:40 AM, "Jon Masamitsu" wrote: > > > On 2/22/2012 4:28 AM, Michael Bien wrote: > >> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >> >>> Posted: http://openjdk.java.net/jeps/**141 >>> >>> - Mark >>> >>> additional risks: >> - JVM may not be able to start >> > > Specifically, the JVM tries to reserve enough memory at start up > for the heap and fails to initialize if it cannot? > > Will add it. > > - could contribute to the false impression that java requires a lot of >> memory to run (JVMs usually don't like to give memory back to the OS once >> its in use) >> > > Is this an impression the user would get because the JVM would not start > up as you > note above? The JVM does not necessarily use all the memory it reserves. > > > Thanks. > > Jon > >> >> best regards, >> michael >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120222/a9752e57/attachment.html From john.cuthbertson at oracle.com Wed Feb 22 12:10:14 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 22 Feb 2012 12:10:14 -0800 Subject: RFR(XXS): 7147806: G1: Crash in vm bootstrap when running with -XX:+UseG1GC -XX:-UsePerfData Message-ID: <4F454BA6.8000201@oracle.com> Hi Everyone, Can I have a couple of volunteers to review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7147806/webrev.0/ The issues here was that some updates to the G1 performance counter variables were not guarded. In the other collectors, the generation and collector performance counters are allocated/initialized unconditionally. The performance counter variables that these counters contain, however, are allocated and updated only if UsePerfData is enabled. In G1, some of these updates were not suitably guarded and so we tried to update some unallocated performance counter variables. Testing: * Small test case (gcbasher) with the offending command line flag combination and with just G1. Thanks, JohnC From mbien at fh-landshut.de Wed Feb 22 12:44:56 2012 From: mbien at fh-landshut.de (Michael Bien) Date: Wed, 22 Feb 2012 21:44:56 +0100 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F450BF2.3030708@oracle.com> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> Message-ID: <4F4553C8.9020206@fh-landshut.de> On 02/22/2012 04:38 PM, Jon Masamitsu wrote: > > > On 2/22/2012 4:28 AM, Michael Bien wrote: >> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >>> Posted: http://openjdk.java.net/jeps/141 >>> >>> - Mark >>> >> additional risks: >> - JVM may not be able to start > > Specifically, the JVM tries to reserve enough memory at start up > for the heap and fails to initialize if it cannot? > > Will add it. > >> - could contribute to the false impression that java requires a lot >> of memory to run (JVMs usually don't like to give memory back to the >> OS once its in use) > > Is this an impression the user would get because the JVM would not > start up as you > note above? The JVM does not necessarily use all the memory it > reserves. yep. However most GCs are quite lazy (by design) to reach good throughput. My experience so far showed that GCs have the tendency to expand the heap at a full GC if there is still room left. Shrinking heaps happened to me only in constructed tests - never in real applications (esp. not with default config ;)). i am somehow not very comfortable with the fact that hello world or an applet would request 1g from the OS. Are there usecases for applications out there where the developer or admin doesn't know how much memory is needed? If there are, than a default value would not help those much anyway (-> expanding heap needed until system limit is reached). All others set -Xmx :) just wanted to bring this up, you guys are the experts. regards, michael > > > Thanks. > > Jon >> >> best regards, >> michael >> > > -- http://michael-bien.com/ From Peter.B.Kessler at Oracle.COM Wed Feb 22 13:10:19 2012 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Wed, 22 Feb 2012 13:10:19 -0800 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F4553C8.9020206@fh-landshut.de> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> Message-ID: <4F4559BB.1040401@Oracle.COM> Michael Bien wrote: > > On 02/22/2012 04:38 PM, Jon Masamitsu wrote: >> >> >> On 2/22/2012 4:28 AM, Michael Bien wrote: >>> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >>>> Posted: http://openjdk.java.net/jeps/141 >>>> >>>> - Mark >>>> >>> additional risks: >>> - JVM may not be able to start >> >> Specifically, the JVM tries to reserve enough memory at start up >> for the heap and fails to initialize if it cannot? >> >> Will add it. >> >>> - could contribute to the false impression that java requires a lot >>> of memory to run (JVMs usually don't like to give memory back to the >>> OS once its in use) >> >> Is this an impression the user would get because the JVM would not >> start up as you >> note above? The JVM does not necessarily use all the memory it >> reserves. > yep. However most GCs are quite lazy (by design) to reach good > throughput. My experience so far showed that GCs have the tendency to > expand the heap at a full GC if there is still room left. Shrinking > heaps happened to me only in constructed tests - never in real > applications (esp. not with default config ;)). > > i am somehow not very comfortable with the fact that hello world or an > applet would request 1g from the OS. Are there usecases for applications > out there where the developer or admin doesn't know how much memory is > needed? If there are, than a default value would not help those much > anyway (-> expanding heap needed until system limit is reached). All > others set -Xmx :) The standard use case is an editor, where the heap needed depends on what's being edited. To use a text example: a short note versus a book chapter. As people's expectations grow for what the editor can do, they use it for larger projects. Sure, at some point they won't have enough heap for some document, and you have to tell them how to work around that limit, but it would be nice if you didn't have to tell everyone how to set -Xmx. Or, as the implementor, I don't want to ship my code with a script that sets -Xmx1g, because then people complain about reserving 1GB for editing a short note. (That said, more efficient memory structures in the application are usually a better solution. :-) This is a specific case of not knowing what the application is going to be used for before it starts up. Short-lived applet in a browser or the 24x7x365 server running on big iron? That's why the JVM has default values, and why they aren't always appropriate, and why we discuss the implications when we think about changing them. ... peter > just wanted to bring this up, you guys are the experts. > > regards, > michael > >> >> >> Thanks. >> >> Jon >>> >>> best regards, >>> michael >>> >> >> > From jon.masamitsu at oracle.com Wed Feb 22 13:20:00 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 22 Feb 2012 13:20:00 -0800 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F4553C8.9020206@fh-landshut.de> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> Message-ID: <4F455C00.1080801@oracle.com> On 2/22/2012 12:44 PM, Michael Bien wrote: > > ... > > i am somehow not very comfortable with the fact that hello world or an > applet would request 1g from the OS. Are there usecases for > applications out there where the developer or admin doesn't know how > much memory is needed? If there are, than a default value would not > help those much anyway (-> expanding heap needed until system limit is > reached). All others set -Xmx :) I think the use case is where an applications is deployed to a variety of machines. Customer A runs on a big machine, gets lots of work thrown at it, wants a big heap. Customer B runs on small machines, etc. and wants a small heap. No one wants to tune if they can help it. :-) Jon > > just wanted to bring this up, you guys are the experts. > > regards, > michael > >> >> >> Thanks. >> >> Jon >>> >>> best regards, >>> michael >>> >> >> > From jon.masamitsu at oracle.com Wed Feb 22 13:45:45 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 22 Feb 2012 13:45:45 -0800 Subject: changing the memory settings semi-dynamically vs GateKeeper and signing In-Reply-To: References: <0BBF8DCB-597D-4838-BC15-79D9DBB42EF2@tagtraum.com> <8EAA9E23-4C8F-4D75-8278-9D859F226CAE@apple.com> Message-ID: <4F456209.2010801@oracle.com> On 2/21/2012 9:49 PM, Srinivas Ramakrishna wrote: > Good points... It's a good idea to cross- post this over to hotspot-gc-dev since it's relevant to "client ergonomics" or current lack thereof.... > > Sent from my iPhone > > On Feb 21, 2012, at 20:54, Andrew Thompson wrote: > >> ... >> But why should this be the behavior? Apps written in Objective C don't self limit, so why not make Xmx default to physical RAM size? Hotspot reserves the address space for the heap at initialization. Having it automatically grab 1gb seems unfriendly to other users of address space within the process and may exclude other process from starting up (depending on how over subscription of memory is handled). A smaller limit on the size of the heap also limits the pause time an application will see. It can also limits throughput but I believe there are many users who prefer the low pause more often rather than the larger pauses less often. Regarding shrinking the heap and giving back the memory, yes, the hotspot should do that. Jon >> I can give at least a partial answer: because most of the Garbage Collectors available for Java NEVER shrink the heap once it grows. What then ends up happening is a "high water mark" effect. Say you have an application that needs to allocate 1.5GB of memory during startup, but once it is up and running it then only needs 500mb? Well, under most Java GCs today the heap is going to grow to at least 1.5GB and never come down again. Let me be clear; the 1.5 GB heap will have 500mb of data and 1gb of free space; it collects the garbage but it never shrinks (gives memory back to the OS).. >> >> In fact, as far as I know only the old serial GC ever gives back memory, but that's not the default collector in a 64bit VM. Parallel GC is. One can use the ergonomics goal settings mentioned here: >> >> http://www.oracle.com/technetwork/java/ergo5-140223.html#1.1.1.Maximum%20pause%20time%20goal%7Coutline >> >> These influence whether the VM collects or grows the heap, but they have no impact on shrinking the heap under the parallel collector. Don't take my word for it, there's a thread on the hotspot-GC-dev list about this, a patch is proposed but the conversation peters out >> >> http://markmail.org/message/xalkitas66s3w7pt#query:+page:1+mid:ci5y6rkvdswbwwhs+state:results >> >> This limitation has a chilling effect as if at anytime an application requires more memory the heap will grow, but when that turns out to be a temporary condition and garbage is collected the heap does not shrink back down again. What person shipping a client-side app would take that risk? >> >> What I'd like to see is something like >> >> initial heap size is ?1/64? physical memory >> >> maximum heap size is equal to physical memory >> >> With heap shrinking working, one could risk not setting Xmx and letting it be physical RAM size because even if the app temporarily uses this much memory, it'll give back when it calms down. >> But since heap shrinking does not work with most GCs, Xmx is here to stay, I fear. From igor.veresov at oracle.com Wed Feb 22 16:38:30 2012 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Feb 2012 16:38:30 -0800 Subject: RFR(XXS): 7147806: G1: Crash in vm bootstrap when running with -XX:+UseG1GC -XX:-UsePerfData In-Reply-To: <4F454BA6.8000201@oracle.com> References: <4F454BA6.8000201@oracle.com> Message-ID: <286A80CBCD114048899EB3EEE626C58A@oracle.com> Looks good. igor On Wednesday, February 22, 2012 at 12:10 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? The > webrev can be found at: http://cr.openjdk.java.net/~johnc/7147806/webrev.0/ > > The issues here was that some updates to the G1 performance counter > variables were not guarded. In the other collectors, the generation and > collector performance counters are allocated/initialized > unconditionally. The performance counter variables that these counters > contain, however, are allocated and updated only if UsePerfData is > enabled. In G1, some of these updates were not suitably guarded and so > we tried to update some unallocated performance counter variables. > > Testing: > * Small test case (gcbasher) with the offending command line flag > combination and with just G1. > > Thanks, > > JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120222/17a7cdd9/attachment.html From mbien at fh-landshut.de Wed Feb 22 17:06:11 2012 From: mbien at fh-landshut.de (Michael Bien) Date: Thu, 23 Feb 2012 02:06:11 +0100 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F4559BB.1040401@Oracle.COM> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> <4F4559BB.1040401@Oracle.COM> Message-ID: <4F459103.8040804@fh-landshut.de> On 02/22/2012 10:10 PM, Peter B. Kessler wrote: > Michael Bien wrote: >> >> On 02/22/2012 04:38 PM, Jon Masamitsu wrote: >>> >>> >>> On 2/22/2012 4:28 AM, Michael Bien wrote: >>>> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >>>>> Posted: http://openjdk.java.net/jeps/141 >>>>> >>>>> - Mark >>>>> >>>> additional risks: >>>> - JVM may not be able to start >>> >>> Specifically, the JVM tries to reserve enough memory at start up >>> for the heap and fails to initialize if it cannot? >>> >>> Will add it. >>> >>>> - could contribute to the false impression that java requires a >>>> lot of memory to run (JVMs usually don't like to give memory back >>>> to the OS once its in use) >>> >>> Is this an impression the user would get because the JVM would not >>> start up as you >>> note above? The JVM does not necessarily use all the memory it >>> reserves. >> yep. However most GCs are quite lazy (by design) to reach good >> throughput. My experience so far showed that GCs have the tendency to >> expand the heap at a full GC if there is still room left. Shrinking >> heaps happened to me only in constructed tests - never in real >> applications (esp. not with default config ;)). >> >> i am somehow not very comfortable with the fact that hello world or >> an applet would request 1g from the OS. Are there usecases for >> applications out there where the developer or admin doesn't know how >> much memory is needed? If there are, than a default value would not >> help those much anyway (-> expanding heap needed until system limit >> is reached). All others set -Xmx :) > > The standard use case is an editor, where the heap needed depends on > what's being edited. To use a text example: a short note versus a > book chapter. As people's expectations grow for what the editor can > do, they use it for larger projects. Sure, at some point they won't > have enough heap for some document, and you have to tell them how to > work around that limit, but it would be nice if you didn't have to > tell everyone how to set -Xmx. Or, as the implementor, I don't want > to ship my code with a script that sets -Xmx1g, because then people > complain about reserving 1GB for editing a short note. (That said, > more efficient memory structures in the application are usually a > better solution. :-) > > This is a specific case of not knowing what the application is going > to be used for before it starts up. Short-lived applet in a browser > or the 24x7x365 server running on big iron? That's why the JVM has > default values, and why they aren't always appropriate, and why we > discuss the implications when we think about changing them. > > ... peter Its great that this kind of topics are discussed. I am a little bit sceptical that anyone will let the JVM pick a value in production and hope the application will work with that default. NetBeans for example uses this approach you mentioned to automatically adjust the max heap size before startup, I am sure eclipse does something similar in its native launcher. Both can do that since both know what the minimum requirements are which are needed to run the editor, everything above that value is nice-to-have and is set if available. The real problems are as you mentioned: - java has no self contained launcher; jigsaw could help here if it would allow to specify jvm flags in the module descriptor - the JVM can not figure out what the application requires (basically not solvable) - the current JVM impl requires an upper heap limit What would be interesting is a flag which specifies a range. For example -Xmx1g_2g. This would tell the JVM to take 2g if possible and scale down to 1g if not. I would even go further and let the JVM print a warning message if xmx has not been specified to discourage not portable deployments. best regards, michael From Peter.B.Kessler at Oracle.COM Wed Feb 22 17:49:20 2012 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Wed, 22 Feb 2012 17:49:20 -0800 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F459103.8040804@fh-landshut.de> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> <4F4559BB.1040401@Oracle.COM> <4F459103.8040804@fh-landshut.de> Message-ID: <4F459B20.1070900@Oracle.COM> I'm in favor of a heap that doesn't need to have a maximum specified, but instead allow the heap to grow as the application demands. We know how to do that, it's just a matter of programming. Compare this to C programs, which just call malloc() until they finish, or run out of address space. There are lots of options along the way: an admin might want to specify a maximum for an application on a shared machine; a launcher might want to see what else was running on the machine and adjust the heap to be polite; the JVM might want to limit the heap to what is available without causing paging; aggressive collection might cause the heap to shrink; etc. ... peter Michael Bien wrote: > > > On 02/22/2012 10:10 PM, Peter B. Kessler wrote: >> Michael Bien wrote: >>> >>> On 02/22/2012 04:38 PM, Jon Masamitsu wrote: >>>> >>>> >>>> On 2/22/2012 4:28 AM, Michael Bien wrote: >>>>> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >>>>>> Posted: http://openjdk.java.net/jeps/141 >>>>>> >>>>>> - Mark >>>>>> >>>>> additional risks: >>>>> - JVM may not be able to start >>>> >>>> Specifically, the JVM tries to reserve enough memory at start up >>>> for the heap and fails to initialize if it cannot? >>>> >>>> Will add it. >>>> >>>>> - could contribute to the false impression that java requires a >>>>> lot of memory to run (JVMs usually don't like to give memory back >>>>> to the OS once its in use) >>>> >>>> Is this an impression the user would get because the JVM would not >>>> start up as you >>>> note above? The JVM does not necessarily use all the memory it >>>> reserves. >>> yep. However most GCs are quite lazy (by design) to reach good >>> throughput. My experience so far showed that GCs have the tendency to >>> expand the heap at a full GC if there is still room left. Shrinking >>> heaps happened to me only in constructed tests - never in real >>> applications (esp. not with default config ;)). >>> >>> i am somehow not very comfortable with the fact that hello world or >>> an applet would request 1g from the OS. Are there usecases for >>> applications out there where the developer or admin doesn't know how >>> much memory is needed? If there are, than a default value would not >>> help those much anyway (-> expanding heap needed until system limit >>> is reached). All others set -Xmx :) >> >> The standard use case is an editor, where the heap needed depends on >> what's being edited. To use a text example: a short note versus a >> book chapter. As people's expectations grow for what the editor can >> do, they use it for larger projects. Sure, at some point they won't >> have enough heap for some document, and you have to tell them how to >> work around that limit, but it would be nice if you didn't have to >> tell everyone how to set -Xmx. Or, as the implementor, I don't want >> to ship my code with a script that sets -Xmx1g, because then people >> complain about reserving 1GB for editing a short note. (That said, >> more efficient memory structures in the application are usually a >> better solution. :-) >> >> This is a specific case of not knowing what the application is going >> to be used for before it starts up. Short-lived applet in a browser >> or the 24x7x365 server running on big iron? That's why the JVM has >> default values, and why they aren't always appropriate, and why we >> discuss the implications when we think about changing them. >> >> ... peter > > Its great that this kind of topics are discussed. I am a little bit > sceptical that anyone will let the JVM pick a value in production and > hope the application will work with that default. NetBeans for example > uses this approach you mentioned to automatically adjust the max heap > size before startup, I am sure eclipse does something similar in its > native launcher. Both can do that since both know what the minimum > requirements are which are needed to run the editor, everything above > that value is nice-to-have and is set if available. > > The real problems are as you mentioned: > - java has no self contained launcher; jigsaw could help here if it > would allow to specify jvm flags in the module descriptor > - the JVM can not figure out what the application requires (basically > not solvable) > - the current JVM impl requires an upper heap limit > > What would be interesting is a flag which specifies a range. For example > -Xmx1g_2g. This would tell the JVM to take 2g if possible and scale down > to 1g if not. > > I would even go further and let the JVM print a warning message if xmx > has not been specified to discourage not portable deployments. > > best regards, > michael > > > > From kirk at kodewerk.com Wed Feb 22 20:20:37 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 23 Feb 2012 05:20:37 +0100 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F459103.8040804@fh-landshut.de> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> <4F4559BB.1040401@Oracle.COM> <4F459103.8040804@fh-landshut.de> Message-ID: Hi, > What would be interesting is a flag which specifies a range. For example -Xmx1g_2g. This would tell the JVM to take 2g if possible and scale down to 1g if not. Current tuning strategy is to use -Xms1g -Xmx2g with parallel collectors as these will adapt. Unfortunately CMS doesn't resize and a Concurrent Mode Failure always happens under conditions where a reduction in size would not be warranted so.. Regards, Kirk From bengt.rutisson at oracle.com Wed Feb 22 23:31:07 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 23 Feb 2012 08:31:07 +0100 Subject: RFR(XXS): 7147806: G1: Crash in vm bootstrap when running with -XX:+UseG1GC -XX:-UsePerfData In-Reply-To: <4F454BA6.8000201@oracle.com> References: <4F454BA6.8000201@oracle.com> Message-ID: <4F45EB3B.3030303@oracle.com> Looks good. What is the integration plan for this? The bug is a P4. Will you try to get it into hs23 or is it enough that this makes it into hs24? Bengt On 2012-02-22 21:10, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7147806/webrev.0/ > > The issues here was that some updates to the G1 performance counter > variables were not guarded. In the other collectors, the generation > and collector performance counters are allocated/initialized > unconditionally. The performance counter variables that these counters > contain, however, are allocated and updated only if UsePerfData is > enabled. In G1, some of these updates were not suitably guarded and so > we tried to update some unallocated performance counter variables. > > Testing: > * Small test case (gcbasher) with the offending command line flag > combination and with just G1. > > Thanks, > > JohnC From mbien at fh-landshut.de Thu Feb 23 00:42:44 2012 From: mbien at fh-landshut.de (Michael Bien) Date: Thu, 23 Feb 2012 09:42:44 +0100 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> <4F4559BB.1040401@Oracle.COM> <4F459103.8040804@fh-landshut.de> Message-ID: <4F45FC04.3000807@fh-landshut.de> On 02/23/2012 05:20 AM, Kirk Pepperdine wrote: > Hi, > >> What would be interesting is a flag which specifies a range. For example -Xmx1g_2g. This would tell the JVM to take 2g if possible and scale down to 1g if not. > Current tuning strategy is to use -Xms1g -Xmx2g with parallel collectors as these will adapt. Unfortunately CMS doesn't resize and a Concurrent Mode Failure always happens under conditions where a reduction in size would not be warranted so.. > > Regards, > Kirk > Exactly. But this is not the same as a Xmx range. Lets assume that the minimum requirements for the given (desktop) application are 1g and 2g are recommended. Specifying -Xms1g -Xmx2g may cause trouble when the OS can not guarantee 2g mem for the VM. A range could tell the VM launcher to retry with a lower value. best regards, michael -- http://michael-bien.com/ From mbien at fh-landshut.de Thu Feb 23 00:55:16 2012 From: mbien at fh-landshut.de (Michael Bien) Date: Thu, 23 Feb 2012 09:55:16 +0100 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: <4F459B20.1070900@Oracle.COM> References: <20120221234824.93D481637@eggemoggin.niobe.net><4F44DF52.3060804@fh-landshut.de> <4F450BF2.3030708@oracle.com> <4F4553C8.9020206@fh-landshut.de> <4F4559BB.1040401@Oracle.COM> <4F459103.8040804@fh-landshut.de> <4F459B20.1070900@Oracle.COM> Message-ID: <4F45FEF4.20802@fh-landshut.de> thanks for brining this up. Thats actually a point i didn't mention explecitly since i always thought it would be a lot of work to rewrite the GCs to work with a non contiguous heap. This would be certainly the best default option for desktop applications. Looking forward to some JRockit-Hotspot integration :) regards, michael On 02/23/2012 02:49 AM, Peter B. Kessler wrote: > I'm in favor of a heap that doesn't need to have a maximum specified, > but instead allow the heap to grow as the application demands. We > know how to do that, it's just a matter of programming. Compare this > to C programs, which just call malloc() until they finish, or run out > of address space. There are lots of options along the way: an admin > might want to specify a maximum for an application on a shared > machine; a launcher might want to see what else was running on the > machine and adjust the heap to be polite; the JVM might want to limit > the heap to what is available without causing paging; aggressive > collection might cause the heap to shrink; etc. > > ... peter > > Michael Bien wrote: >> >> >> On 02/22/2012 10:10 PM, Peter B. Kessler wrote: >>> Michael Bien wrote: >>>> >>>> On 02/22/2012 04:38 PM, Jon Masamitsu wrote: >>>>> >>>>> >>>>> On 2/22/2012 4:28 AM, Michael Bien wrote: >>>>>> On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote: >>>>>>> Posted: http://openjdk.java.net/jeps/141 >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>> additional risks: >>>>>> - JVM may not be able to start >>>>> >>>>> Specifically, the JVM tries to reserve enough memory at start up >>>>> for the heap and fails to initialize if it cannot? >>>>> >>>>> Will add it. >>>>> >>>>>> - could contribute to the false impression that java requires a >>>>>> lot of memory to run (JVMs usually don't like to give memory back >>>>>> to the OS once its in use) >>>>> >>>>> Is this an impression the user would get because the JVM would not >>>>> start up as you >>>>> note above? The JVM does not necessarily use all the memory it >>>>> reserves. >>>> yep. However most GCs are quite lazy (by design) to reach good >>>> throughput. My experience so far showed that GCs have the tendency >>>> to expand the heap at a full GC if there is still room left. >>>> Shrinking heaps happened to me only in constructed tests - never in >>>> real applications (esp. not with default config ;)). >>>> >>>> i am somehow not very comfortable with the fact that hello world or >>>> an applet would request 1g from the OS. Are there usecases for >>>> applications out there where the developer or admin doesn't know >>>> how much memory is needed? If there are, than a default value would >>>> not help those much anyway (-> expanding heap needed until system >>>> limit is reached). All others set -Xmx :) >>> >>> The standard use case is an editor, where the heap needed depends on >>> what's being edited. To use a text example: a short note versus a >>> book chapter. As people's expectations grow for what the editor can >>> do, they use it for larger projects. Sure, at some point they won't >>> have enough heap for some document, and you have to tell them how to >>> work around that limit, but it would be nice if you didn't have to >>> tell everyone how to set -Xmx. Or, as the implementor, I don't want >>> to ship my code with a script that sets -Xmx1g, because then people >>> complain about reserving 1GB for editing a short note. (That said, >>> more efficient memory structures in the application are usually a >>> better solution. :-) >>> >>> This is a specific case of not knowing what the application is going >>> to be used for before it starts up. Short-lived applet in a browser >>> or the 24x7x365 server running on big iron? That's why the JVM has >>> default values, and why they aren't always appropriate, and why we >>> discuss the implications when we think about changing them. >>> >>> ... peter >> >> Its great that this kind of topics are discussed. I am a little bit >> sceptical that anyone will let the JVM pick a value in production and >> hope the application will work with that default. NetBeans for >> example uses this approach you mentioned to automatically adjust the >> max heap size before startup, I am sure eclipse does something >> similar in its native launcher. Both can do that since both know what >> the minimum requirements are which are needed to run the editor, >> everything above that value is nice-to-have and is set if available. >> >> The real problems are as you mentioned: >> - java has no self contained launcher; jigsaw could help here if it >> would allow to specify jvm flags in the module descriptor >> - the JVM can not figure out what the application requires >> (basically not solvable) >> - the current JVM impl requires an upper heap limit >> >> What would be interesting is a flag which specifies a range. For >> example -Xmx1g_2g. This would tell the JVM to take 2g if possible and >> scale down to 1g if not. >> >> I would even go further and let the JVM print a warning message if >> xmx has not been specified to discourage not portable deployments. >> >> best regards, >> michael >> >> >> >> > > -- http://michael-bien.com/ From tony.printezis at oracle.com Thu Feb 23 05:59:13 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 23 Feb 2012 08:59:13 -0500 Subject: RFR(XXS): 7147806: G1: Crash in vm bootstrap when running with -XX:+UseG1GC -XX:-UsePerfData In-Reply-To: <4F45EB3B.3030303@oracle.com> References: <4F454BA6.8000201@oracle.com> <4F45EB3B.3030303@oracle.com> Message-ID: <4F464631.7090906@oracle.com> Bengt, My opinion: for small, low risk fixes like this one it'd be a good idea to try to get them into hs23. On the other hand: given that clearly noone has been testing with -UsePerfData maybe it doesn't matter. :-) Tony On 02/23/2012 02:31 AM, Bengt Rutisson wrote: > > Looks good. > > What is the integration plan for this? The bug is a P4. Will you try > to get it into hs23 or is it enough that this makes it into hs24? > > Bengt > > On 2012-02-22 21:10, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review the changes for this CR? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7147806/webrev.0/ >> >> The issues here was that some updates to the G1 performance counter >> variables were not guarded. In the other collectors, the generation >> and collector performance counters are allocated/initialized >> unconditionally. The performance counter variables that these >> counters contain, however, are allocated and updated only if >> UsePerfData is enabled. In G1, some of these updates were not >> suitably guarded and so we tried to update some unallocated >> performance counter variables. >> >> Testing: >> * Small test case (gcbasher) with the offending command line flag >> combination and with just G1. >> >> Thanks, >> >> JohnC > From john.cuthbertson at oracle.com Thu Feb 23 08:51:37 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 23 Feb 2012 08:51:37 -0800 Subject: RFR(XXS): 7147806: G1: Crash in vm bootstrap when running with -XX:+UseG1GC -XX:-UsePerfData In-Reply-To: <4F45EB3B.3030303@oracle.com> References: <4F454BA6.8000201@oracle.com> <4F45EB3B.3030303@oracle.com> Message-ID: <4F466E99.1060801@oracle.com> Hi Bengt, Thanks for looking at it. I'm not sure of the integration plan for this but thought it would be better that it was ready (and low-risk enough for hs23) in case we decide to include it. JohnC On 2/22/2012 11:31 PM, Bengt Rutisson wrote: > > Looks good. > > What is the integration plan for this? The bug is a P4. Will you try > to get it into hs23 or is it enough that this makes it into hs24? > > Bengt > > On 2012-02-22 21:10, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review the changes for this CR? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7147806/webrev.0/ >> >> The issues here was that some updates to the G1 performance counter >> variables were not guarded. In the other collectors, the generation >> and collector performance counters are allocated/initialized >> unconditionally. The performance counter variables that these >> counters contain, however, are allocated and updated only if >> UsePerfData is enabled. In G1, some of these updates were not >> suitably guarded and so we tried to update some unallocated >> performance counter variables. >> >> Testing: >> * Small test case (gcbasher) with the offending command line flag >> combination and with just G1. >> >> Thanks, >> >> JohnC > From jon.masamitsu at oracle.com Thu Feb 23 09:59:35 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 23 Feb 2012 09:59:35 -0800 Subject: changing the memory settings semi-dynamically vs GateKeeper and signing In-Reply-To: <5042538A-9440-4C06-9D00-4642077DD359@mac.com> References: <0BBF8DCB-597D-4838-BC15-79D9DBB42EF2@tagtraum.com> <8EAA9E23-4C8F-4D75-8278-9D859F226CAE@apple.com> <4F456209.2010801@oracle.com> <5042538A-9440-4C06-9D00-4642077DD359@mac.com> Message-ID: <4F467E87.2010700@oracle.com> On 02/22/12 21:07, Andrew Thompson wrote: > > On Feb 22, 2012, at 4:45 PM, Jon Masamitsu wrote: > > > Thanks for the response Jon. I realize this isn't any easy problem to > solve because of the huge variations in kinds of programs out there, > not to mention reasonable people differ on what is desirable behavior. > Still, I feel the settings we have for the VM are heavily slanted > towards server deployment where total amount of RAM on the host is a > known quantity, and the total number of apps is usually fixed. > > Contrast the client where: > > - every PC or Mac may have a different amount of RAM > - users may be starting up and shutting down programs constantly > - users expect to be able to open huge files, limited only by the > amount of RAM they bought. > > With that model, guessing what to put in -Xmx is borderline impossible. > > More comments inline below > >> >> On 2/21/2012 9:49 PM, Srinivas Ramakrishna wrote: >>> Good points... It's a good idea to cross- post this over to >>> hotspot-gc-dev since it's relevant to "client ergonomics" or current >>> lack thereof.... >>> >>> Sent from my iPhone >>> >>> On Feb 21, 2012, at 20:54, Andrew Thompson>> > wrote: >>> >>>> ... >>>> But why should this be the behavior? Apps written in Objective C >>>> don't self limit, so why not make Xmx default to physical RAM size? >> >> Hotspot reserves the address space for the heap at initialization. >> Having it automatically >> grab 1gb seems unfriendly to other users of address space within the >> process and may >> exclude other process from starting up (depending on how over >> subscription of memory >> is handled). > > Is that really a concern on a 64bit VM? I know it is a huge concern on > 32bit (e.g. I have never gotten WIndows XP to go beyond a 1GB Xmx > reliably on 32 bit) but for 64 bit the address space is at least > several GB, right? > It seems to me that the design of G1 would one day allow discontiguous > heaps where the memory need not be reserved at startup as a single > piece, but isn't that already irrelevant on 64bit? You're absolutely right. 64bit is not a concern. And in 32bit it's as much a matter of having the card table cover the heap as the heap itself. > > >> A smaller limit on the size of the heap also limits the pause time >> an application will see. >> It can also limits throughput but I believe there are many users who >> prefer the low pause >> more often rather than the larger pauses less often. > > I can more or less control this today. I can do something like > > -Xmx = 128m > -XX:GCTimeRatio=19, > -XX:MaxGCPauseMillis=1000 > > Then the parallel collector will respond by not growing the heap as > much... it prefers to collect over grow on more occasions. > So it is possible to keep some of the benefits of a smaller heap. > > But the real issue is these 2 flags do nothing to the parallel > collector, which creates the highwatermark effect > > -XX:MaxHeapFreeRatio=YY > -XX:MinHeapFreeRatio=ZZ > > Since mx is small the actual used amount of memory (not address space) > starts low, can go up, but can't go down again unless one is running > serlal gc. > This is what I think we are missing in the desktops apps. mx is hard > to predict so rather than do what why not let Hotspot grab a block of > address space for a potentially large heap and let it (the heap's > data) grow and shrink as needed. The part about the heap not shrinking is a bug. > >> Regarding shrinking the heap and giving back the memory, yes, the >> hotspot should do >> that. > \ > So was there a fundamental flaw with last year's patch? It caused more > gcs but was there a showstopper problem with it or did the developer > just lose interest? > I believe you are referring to a contribution from a Google engineer. It got complicated in a non-technical way. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120223/1e465e77/attachment.html From lordpixel at me.com Thu Feb 23 04:08:20 2012 From: lordpixel at me.com (Andrew Thompson) Date: Thu, 23 Feb 2012 07:08:20 -0500 Subject: changing the memory settings semi-dynamically vs GateKeeper and signing In-Reply-To: <5042538A-9440-4C06-9D00-4642077DD359@mac.com> References: <0BBF8DCB-597D-4838-BC15-79D9DBB42EF2@tagtraum.com> <8EAA9E23-4C8F-4D75-8278-9D859F226CAE@apple.com> <4F456209.2010801@oracle.com> <5042538A-9440-4C06-9D00-4642077DD359@mac.com> Message-ID: <4F2315E5-47C3-4EE1-9ECE-08044228F5E6@me.com> On Feb 23, 2012, at 12:07 AM, Andrew Thompson wrote: Apologies for replying to myself, but I realized I have a persistent typo (mx where I meant ms) which renders the last part of the email unintelligible > >> A smaller limit on the size of the heap also limits the pause time an application will see. >> It can also limits throughput but I believe there are many users who prefer the low pause >> more often rather than the larger pauses less often. > > I can more or less control this today. I can do something like > > -Xmx = 128m > -XX:GCTimeRatio=19, > -XX:MaxGCPauseMillis=1000 Here I meant -Xms=128m, allowing Xmx to take a much larger value thru ergonomics, or alternatively specifying a large -Xmx > > Then the parallel collector will respond by not growing the heap as much... it prefers to collect over grow on more occasions. > So it is possible to keep some of the benefits of a smaller heap. > > But the real issue is these 2 flags do nothing to the parallel collector, which creates the highwatermark effect > > -XX:MaxHeapFreeRatio=YY > -XX:MinHeapFreeRatio=ZZ > > Since mx is small the actual used amount of memory (not address space) starts low, can go up, but can't go down again unless one is running serlal gc. > This is what I think we are missing in the desktops apps. mx is hard to predict so rather than do what why not let Hotspot grab a block of address space for a potentially large heap and let it (the heap's data) grow and shrink as needed. Here again I meant to say "Since ms is small..." > >> Regarding shrinking the heap and giving back the memory, yes, the hotspot should do >> that. > \ > So was there a fundamental flaw with last year's patch? It caused more gcs but was there a showstopper problem with it or did the developer just lose interest? > I am happy to enter a couple of enhancement requests if you would like the feedback to be recorded - that G1 and/or Parallelgc should be able to shrink the heap, respecting MaxHeapFreeRatio/MinHeapFreeRatio or some similar settings - that it would be good to have some kind of switch, say -XXaggressiveErgonomics ;-), which cause the Xms value to default low, the Xmx value to default to a significant fraction of physical ram and let the VM grow and shrink the heap within these large bounds - I suppose a 3rd ticket could be about G1 being able to manage discontiguous heaps, because ultimately isn't this the ultimate flexibility... being able to really add and remove blocks of address space to the heap on demand? AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me) From bengt.rutisson at oracle.com Thu Feb 23 12:47:32 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 23 Feb 2012 21:47:32 +0100 Subject: RFR(XXS): 7147806: G1: Crash in vm bootstrap when running with -XX:+UseG1GC -XX:-UsePerfData In-Reply-To: <4F466E99.1060801@oracle.com> References: <4F454BA6.8000201@oracle.com> <4F45EB3B.3030303@oracle.com> <4F466E99.1060801@oracle.com> Message-ID: <4F46A5E4.8050902@oracle.com> Hi John, On 2012-02-23 17:51, John Cuthbertson wrote: > Hi Bengt, > > Thanks for looking at it. I'm not sure of the integration plan for > this but thought it would be better that it was ready (and low-risk > enough for hs23) in case we decide to include it. I'm fine with it going into hs23. I was just wondering if it was worth the extra work of asking for release team approval since we have to do that now for hs23 stuff. Either way is fine with me. Bengt > > JohnC > > On 2/22/2012 11:31 PM, Bengt Rutisson wrote: >> >> Looks good. >> >> What is the integration plan for this? The bug is a P4. Will you try >> to get it into hs23 or is it enough that this makes it into hs24? >> >> Bengt >> >> On 2012-02-22 21:10, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers to review the changes for this CR? >>> The webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/7147806/webrev.0/ >>> >>> The issues here was that some updates to the G1 performance counter >>> variables were not guarded. In the other collectors, the generation >>> and collector performance counters are allocated/initialized >>> unconditionally. The performance counter variables that these >>> counters contain, however, are allocated and updated only if >>> UsePerfData is enabled. In G1, some of these updates were not >>> suitably guarded and so we tried to update some unallocated >>> performance counter variables. >>> >>> Testing: >>> * Small test case (gcbasher) with the offending command line flag >>> combination and with just G1. >>> >>> Thanks, >>> >>> JohnC >> From bengt.rutisson at oracle.com Thu Feb 23 13:45:26 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 23 Feb 2012 21:45:26 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7148152: Add whitebox testing API to HotSpot Message-ID: <20120223214533.B3B0547674@hg.openjdk.java.net> Changeset: 2d503de963b3 Author: mgerdin Date: 2012-02-23 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 7148152: Add whitebox testing API to HotSpot Summary: Add an internal testing API to HotSpot to enable more targeted testing of vm functionality Reviewed-by: phh, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/vm.make + make/bsd/makefiles/wb.make ! make/jprt.properties ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make + make/linux/makefiles/wb.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make + make/solaris/makefiles/wb.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make + make/windows/makefiles/wb.make + src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/prims/nativeLookup.cpp + src/share/vm/prims/whitebox.cpp + src/share/vm/prims/whitebox.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp ! test/Makefile + test/sanity/WBApi.java From bengt.rutisson at oracle.com Fri Feb 24 04:14:13 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 24 Feb 2012 13:14:13 +0100 Subject: Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: References: Message-ID: <4F477F15.20908@oracle.com> Hi all, Just pinging this review request. Does anybody have some time to look at it? It is a fairly small and straight forward change... Thanks, Bengt -------- Original Message -------- Subject: Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning Date: Tue, 21 Feb 2012 12:03:50 +0400 From: Alexey Ragozin To: hotspot-gc-dev at openjdk.java.net CC: Bengt Rutisson Hi, I would like few volunteers to review changes for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ Change summary For large heaps (I was focusing on 8GiB and above) it is common to have long continuous ranges of clean cards. Patch is introducing a short path for skipping ranges of clean cards using word aligned memory access instead of byte aligned. Patch affects serial and CMS collectors. For CMS collector stride size should be increase to see any performance gains (I was using -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=4096) For testing I was mainly using synthetic benchmark randomly modifying hash tables in heap, thus uniformly touching cards across heaps. Average duration of young GC pause were used as KPI. More details about testing can be found at http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html Though article is referring jdk6, my resent tests with trunk jdk7 show no difference. I was also tested patch with real application (Oracle Coherence storage node). With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC pauses roughly in 2 times. Source code of benchmark used in test are available at https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench Main class YoungGCPauseBenchmark Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120224/1c3b8b70/attachment.html From jesper.wilhelmsson at oracle.com Fri Feb 24 04:50:42 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 24 Feb 2012 13:50:42 +0100 Subject: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: <4F477F15.20908@oracle.com> References: <4F477F15.20908@oracle.com> Message-ID: <5B839334-95F3-47DB-801F-609C924379E9@oracle.com> I can have a look at it but I don't have the time to do it today. If Monday is OK then I can take it. /Jesper 24 feb 2012 kl. 13:14 skrev Bengt Rutisson : > > Hi all, > > Just pinging this review request. Does anybody have some time to look at it? It is a fairly small and straight forward change... > > Thanks, > Bengt > > -------- Original Message -------- > Subject: Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning > Date: Tue, 21 Feb 2012 12:03:50 +0400 > From: Alexey Ragozin > To: hotspot-gc-dev at openjdk.java.net > CC: Bengt Rutisson > > Hi, > > I would like few volunteers to review changes for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ > > Change summary > For large heaps (I was focusing on 8GiB and above) it is common to have long continuous ranges of clean cards. > Patch is introducing a short path for skipping ranges of clean cards using word aligned memory access instead of byte aligned. > > Patch affects serial and CMS collectors. For CMS collector stride size should be increase to see any performance gains (I was using > -XX:+UnlockDiagnosticVMOptions > -XX:ParGCCardsPerStrideChunk=4096) > > For testing I was mainly using synthetic benchmark randomly modifying hash tables in heap, thus uniformly touching cards across heaps. > Average duration of young GC pause were used as KPI. > More details about testing can be found at > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html > Though article is referring jdk6, my resent tests with trunk jdk7 show no difference. > I was also tested patch with real application (Oracle Coherence storage node). > With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC pauses roughly in 2 times. > > Source code of benchmark used in test are available at > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench > Main class YoungGCPauseBenchmark > > Regards, > Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120224/719dea8a/attachment.html From bengt.rutisson at oracle.com Fri Feb 24 04:53:19 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 24 Feb 2012 13:53:19 +0100 Subject: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: <5B839334-95F3-47DB-801F-609C924379E9@oracle.com> References: <4F477F15.20908@oracle.com> <5B839334-95F3-47DB-801F-609C924379E9@oracle.com> Message-ID: <4F47883F.9000806@oracle.com> On 2012-02-24 13:50, Jesper Wilhelmsson wrote: > I can have a look at it but I don't have the time to do it today. If > Monday is OK then I can take it. Thanks, Jesper! Will also need a second review from someone with OpenJDK reviewer status. Bengt > /Jesper > > > > 24 feb 2012 kl. 13:14 skrev Bengt Rutisson >: > >> >> Hi all, >> >> Just pinging this review request. Does anybody have some time to look >> at it? It is a fairly small and straight forward change... >> >> Thanks, >> Bengt >> >> -------- Original Message -------- >> Subject: Request for review (S): 7068625 Testing 8 bytes of card >> table entries at a time speeds up card-scanning >> Date: Tue, 21 Feb 2012 12:03:50 +0400 >> From: Alexey Ragozin >> To: hotspot-gc-dev at openjdk.java.net >> CC: Bengt Rutisson >> >> >> >> Hi, >> >> I would like few volunteers to review changes for >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 >> WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ >> >> >> Change summary >> For large heaps (I was focusing on 8GiB and above) it is common to >> have long continuous ranges of clean cards. >> Patch is introducing a short path for skipping ranges of clean cards >> using word aligned memory access instead of byte aligned. >> >> Patch affects serial and CMS collectors. For CMS collector stride >> size should be increase to see any performance gains (I was using >> -XX:+UnlockDiagnosticVMOptions >> -XX:ParGCCardsPerStrideChunk=4096) >> >> For testing I was mainly using synthetic benchmark randomly modifying >> hash tables in heap, thus uniformly touching cards across heaps. >> Average duration of young GC pause were used as KPI. >> More details about testing can be found at >> http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html >> Though article is referring jdk6, my resent tests with trunk jdk7 >> show no difference. >> I was also tested patch with real application (Oracle Coherence >> storage node). >> With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened >> GC pauses roughly in 2 times. >> >> Source code of benchmark used in test are available at >> https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench >> Main class YoungGCPauseBenchmark >> >> Regards, >> Alexey >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120224/858422b3/attachment-0001.html From jon.masamitsu at oracle.com Fri Feb 24 07:36:11 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Feb 2012 07:36:11 -0800 Subject: Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: <4F477F15.20908@oracle.com> References: <4F477F15.20908@oracle.com> Message-ID: <4F47AE6B.1030702@oracle.com> Bengt, I'll look at this today. Jon On 2/24/2012 4:14 AM, Bengt Rutisson wrote: > > Hi all, > > Just pinging this review request. Does anybody have some time to look > at it? It is a fairly small and straight forward change... > > Thanks, > Bengt > > -------- Original Message -------- > Subject: Request for review (S): 7068625 Testing 8 bytes of card > table entries at a time speeds up card-scanning > Date: Tue, 21 Feb 2012 12:03:50 +0400 > From: Alexey Ragozin > To: hotspot-gc-dev at openjdk.java.net > CC: Bengt Rutisson > > > > Hi, > > I would like few volunteers to review changes for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ > > > Change summary > For large heaps (I was focusing on 8GiB and above) it is common to > have long continuous ranges of clean cards. > Patch is introducing a short path for skipping ranges of clean cards > using word aligned memory access instead of byte aligned. > > Patch affects serial and CMS collectors. For CMS collector stride size > should be increase to see any performance gains (I was using > -XX:+UnlockDiagnosticVMOptions > -XX:ParGCCardsPerStrideChunk=4096) > > For testing I was mainly using synthetic benchmark randomly modifying > hash tables in heap, thus uniformly touching cards across heaps. > Average duration of young GC pause were used as KPI. > More details about testing can be found at > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html > Though article is referring jdk6, my resent tests with trunk jdk7 show > no difference. > I was also tested patch with real application (Oracle Coherence > storage node). > With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC > pauses roughly in 2 times. > > Source code of benchmark used in test are available at > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench > > Main class YoungGCPauseBenchmark > > Regards, > Alexey > > From tom.rodriguez at oracle.com Fri Feb 24 10:28:31 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 24 Feb 2012 10:28:31 -0800 Subject: PrintGCTaskTimeStamps Message-ID: I'm looking at the uses of os::elapsedTime and TimeStamp and trying to rationalize them a bit, mainly by eliminating TimeStamp. I noticed that the code for PrintGCTaskTimeStamps effectively prints out the raw ticks from os::elapsed_counter() without scaling them to a particular time base. What's the intent of this output? Is it assuming nanos? tom From jon.masamitsu at oracle.com Fri Feb 24 11:40:39 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Feb 2012 11:40:39 -0800 Subject: Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: <4F477F15.20908@oracle.com> References: <4F477F15.20908@oracle.com> Message-ID: <4F47E7B7.6090407@oracle.com> Alexey, Change looks good. Did you run the tests on 32bit and smaller heaps (~4G)? That would give you 4byte rows (instead of 8byte rows), right? Jon On 2/24/2012 4:14 AM, Bengt Rutisson wrote: > > Hi all, > > Just pinging this review request. Does anybody have some time to look > at it? It is a fairly small and straight forward change... > > Thanks, > Bengt > > -------- Original Message -------- > Subject: Request for review (S): 7068625 Testing 8 bytes of card > table entries at a time speeds up card-scanning > Date: Tue, 21 Feb 2012 12:03:50 +0400 > From: Alexey Ragozin > To: hotspot-gc-dev at openjdk.java.net > CC: Bengt Rutisson > > > > Hi, > > I would like few volunteers to review changes for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ > > > Change summary > For large heaps (I was focusing on 8GiB and above) it is common to > have long continuous ranges of clean cards. > Patch is introducing a short path for skipping ranges of clean cards > using word aligned memory access instead of byte aligned. > > Patch affects serial and CMS collectors. For CMS collector stride size > should be increase to see any performance gains (I was using > -XX:+UnlockDiagnosticVMOptions > -XX:ParGCCardsPerStrideChunk=4096) > > For testing I was mainly using synthetic benchmark randomly modifying > hash tables in heap, thus uniformly touching cards across heaps. > Average duration of young GC pause were used as KPI. > More details about testing can be found at > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html > Though article is referring jdk6, my resent tests with trunk jdk7 show > no difference. > I was also tested patch with real application (Oracle Coherence > storage node). > With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC > pauses roughly in 2 times. > > Source code of benchmark used in test are available at > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench > > Main class YoungGCPauseBenchmark > > Regards, > Alexey > > From jon.masamitsu at oracle.com Fri Feb 24 11:50:15 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Feb 2012 11:50:15 -0800 Subject: PrintGCTaskTimeStamps In-Reply-To: References: Message-ID: <4F47E9F7.8040202@oracle.com> Tom, I think that James used this as input to the Timeline program which he used to visualize how well work was balanced among GC workers. Relative values where the only thing that mattered (not any units). Jon On 2/24/2012 10:28 AM, Tom Rodriguez wrote: > I'm looking at the uses of os::elapsedTime and TimeStamp and trying to rationalize them a bit, mainly by eliminating TimeStamp. I noticed that the code for PrintGCTaskTimeStamps effectively prints out the raw ticks from os::elapsed_counter() without scaling them to a particular time base. What's the intent of this output? Is it assuming nanos? > > tom From jesper.wilhelmsson at oracle.com Mon Feb 27 05:32:20 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 27 Feb 2012 14:32:20 +0100 Subject: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: <4F47883F.9000806@oracle.com> References: <4F477F15.20908@oracle.com> <5B839334-95F3-47DB-801F-609C924379E9@oracle.com> <4F47883F.9000806@oracle.com> Message-ID: <4F4B85E4.2040705@oracle.com> Looks good! A few minor details: In cardTableModRefBS.hpp, maybe it's just me (after all, it's Monday) but I don't understand the comment: "a word worth row of clean card values" From the code I understand what the constant is used for, but it could be more explicitly said in the comment. Maybe something like: "A full word with clean card marks. Used for fast traversal of empty regions in the card table." In cardTableRS.hpp, again in the comment: "making this constants" Should it be "this constant" or "these constants"? On which platform did this kill performance? I think this should be explicitly stated. How much has this been verified? /Jesper On 2012-02-24 13:53, Bengt Rutisson wrote: > > On 2012-02-24 13:50, Jesper Wilhelmsson wrote: >> I can have a look at it but I don't have the time to do it today. If Monday >> is OK then I can take it. > > Thanks, Jesper! > > Will also need a second review from someone with OpenJDK reviewer status. > > Bengt > >> /Jesper >> >> >> >> 24 feb 2012 kl. 13:14 skrev Bengt Rutisson > >: >> >>> >>> Hi all, >>> >>> Just pinging this review request. Does anybody have some time to look at it? >>> It is a fairly small and straight forward change... >>> >>> Thanks, >>> Bengt >>> >>> -------- Original Message -------- >>> Subject: Request for review (S): 7068625 Testing 8 bytes of card table >>> entries at a time speeds up card-scanning >>> Date: Tue, 21 Feb 2012 12:03:50 +0400 >>> From: Alexey Ragozin >>> To: hotspot-gc-dev at openjdk.java.net >>> CC: Bengt Rutisson >>> >>> >>> >>> Hi, >>> >>> I would like few volunteers to review changes for >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 >>> WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ >>> >>> >>> Change summary >>> For large heaps (I was focusing on 8GiB and above) it is common to have long >>> continuous ranges of clean cards. >>> Patch is introducing a short path for skipping ranges of clean cards using >>> word aligned memory access instead of byte aligned. >>> >>> Patch affects serial and CMS collectors. For CMS collector stride size >>> should be increase to see any performance gains (I was using >>> -XX:+UnlockDiagnosticVMOptions >>> -XX:ParGCCardsPerStrideChunk=4096) >>> >>> For testing I was mainly using synthetic benchmark randomly modifying hash >>> tables in heap, thus uniformly touching cards across heaps. >>> Average duration of young GC pause were used as KPI. >>> More details about testing can be found at >>> http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html >>> Though article is referring jdk6, my resent tests with trunk jdk7 show no >>> difference. >>> I was also tested patch with real application (Oracle Coherence storage node). >>> With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC >>> pauses roughly in 2 times. >>> >>> Source code of benchmark used in test are available at >>> https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench >>> Main class YoungGCPauseBenchmark >>> >>> Regards, >>> Alexey >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: jesper_wilhelmsson.vcf Type: text/x-vcard Size: 262 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120227/8cc44c8e/jesper_wilhelmsson.vcf From alexey.ragozin at gmail.com Mon Feb 27 07:31:49 2012 From: alexey.ragozin at gmail.com (Alexey Ragozin) Date: Mon, 27 Feb 2012 19:31:49 +0400 Subject: Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning Message-ID: Hi Jon, Bengt has ran patch trough JPRT, so it should cover 32 bit systems. I havn't done any specific testing to 32 system. Reason is that for small heaps, dirty cards are more dense and scanning heap is taking order of magnitude more time than card table scanning. Practical impact of patch is starting to show up with heaps around 8GiB (30GiB was upper limit for my research) thus making 32 bit JVM not very interesting. Regards, Alexey From: Jon Masamitsu > Subject: Re: Fwd: (resend) Request for review (S): 7068625 Testing 8 > bytes of card table entries at a time speeds up card-scanning > To: hotspot-gc-dev at openjdk.java.net > Message-ID: <4F47E7B7.6090407 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Alexey, > > Change looks good. > > Did you run the tests on 32bit and smaller heaps (~4G)? > That would give you 4byte rows (instead of 8byte rows), > right? > > Jon > > On 2/24/2012 4:14 AM, Bengt Rutisson wrote: > > > > Hi all, > > > > Just pinging this review request. Does anybody have some time to look > > at it? It is a fairly small and straight forward change... > > > > Thanks, > > Bengt > > > > -------- Original Message -------- > > Subject: Request for review (S): 7068625 Testing 8 bytes of card > > table entries at a time speeds up card-scanning > > Date: Tue, 21 Feb 2012 12:03:50 +0400 > > From: Alexey Ragozin > > To: hotspot-gc-dev at openjdk.java.net > > CC: Bengt Rutisson > > > > > > > > Hi, > > > > I would like few volunteers to review changes for > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 > > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ > > > > > > Change summary > > For large heaps (I was focusing on 8GiB and above) it is common to > > have long continuous ranges of clean cards. > > Patch is introducing a short path for skipping ranges of clean cards > > using word aligned memory access instead of byte aligned. > > > > Patch affects serial and CMS collectors. For CMS collector stride size > > should be increase to see any performance gains (I was using > > -XX:+UnlockDiagnosticVMOptions > > -XX:ParGCCardsPerStrideChunk=4096) > > > > For testing I was mainly using synthetic benchmark randomly modifying > > hash tables in heap, thus uniformly touching cards across heaps. > > Average duration of young GC pause were used as KPI. > > More details about testing can be found at > > > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html > > Though article is referring jdk6, my resent tests with trunk jdk7 show > > no difference. > > I was also tested patch with real application (Oracle Coherence > > storage node). > > With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC > > pauses roughly in 2 times. > > > > Source code of benchmark used in test are available at > > > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench > > > > Main class YoungGCPauseBenchmark > > > > Regards, > > Alexey > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120227/4a1f756d/attachment.html From jon.masamitsu at oracle.com Mon Feb 27 10:41:17 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 27 Feb 2012 10:41:17 -0800 Subject: Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: References: Message-ID: <4F4BCE4D.4030902@oracle.com> Alexey, A factor of 2 improvement on large heaps is impressive but something more modest on small heaps would be welcome and I wondered whether it was worth trying to do 8 bytes rows on a 32 bit system. The current implementation does 4 bytes rows on a 32 bit system, correct? Jon On 02/27/12 07:31, Alexey Ragozin wrote: > Hi Jon, > > Bengt has ran patch trough JPRT, so it should cover 32 bit systems. I > havn't done any specific testing to 32 system. > Reason is that for small heaps, dirty cards are more dense and > scanning heap is taking order of magnitude more time than card table > scanning. > > Practical impact of patch is starting to show up with heaps around > 8GiB (30GiB was upper limit for my research) thus making 32 bit JVM > not very interesting. > > Regards, > Alexey > > > From: Jon Masamitsu > > Subject: Re: Fwd: (resend) Request for review (S): 7068625 Testing 8 > bytes of card table entries at a time speeds up card-scanning > To: hotspot-gc-dev at openjdk.java.net > > Message-ID: <4F47E7B7.6090407 at oracle.com > > > Content-Type: text/plain; charset=UTF-8; format=flowed > > Alexey, > > Change looks good. > > Did you run the tests on 32bit and smaller heaps (~4G)? > That would give you 4byte rows (instead of 8byte rows), > right? > > Jon > > On 2/24/2012 4:14 AM, Bengt Rutisson wrote: > > > > Hi all, > > > > Just pinging this review request. Does anybody have some time to look > > at it? It is a fairly small and straight forward change... > > > > Thanks, > > Bengt > > > > -------- Original Message -------- > > Subject: Request for review (S): 7068625 Testing 8 bytes of card > > table entries at a time speeds up card-scanning > > Date: Tue, 21 Feb 2012 12:03:50 +0400 > > From: Alexey Ragozin > > > To: hotspot-gc-dev at openjdk.java.net > > > CC: Bengt Rutisson > > > > > > > > > Hi, > > > > I would like few volunteers to review changes for > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 > > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ > > > > > > > Change summary > > For large heaps (I was focusing on 8GiB and above) it is common to > > have long continuous ranges of clean cards. > > Patch is introducing a short path for skipping ranges of clean cards > > using word aligned memory access instead of byte aligned. > > > > Patch affects serial and CMS collectors. For CMS collector stride > size > > should be increase to see any performance gains (I was using > > -XX:+UnlockDiagnosticVMOptions > > -XX:ParGCCardsPerStrideChunk=4096) > > > > For testing I was mainly using synthetic benchmark randomly modifying > > hash tables in heap, thus uniformly touching cards across heaps. > > Average duration of young GC pause were used as KPI. > > More details about testing can be found at > > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html > > Though article is referring jdk6, my resent tests with trunk jdk7 > show > > no difference. > > I was also tested patch with real application (Oracle Coherence > > storage node). > > With 16GiB of heap and CMS/ParNew GC, enabling patch have > shortened GC > > pauses roughly in 2 times. > > > > Source code of benchmark used in test are available at > > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench > > > > Main class YoungGCPauseBenchmark > > > > Regards, > > Alexey > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120227/f8e3554a/attachment-0001.html From John.Coomes at oracle.com Mon Feb 27 18:48:57 2012 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 27 Feb 2012 18:48:57 -0800 Subject: Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning In-Reply-To: <4F477F15.20908@oracle.com> References: <4F477F15.20908@oracle.com> Message-ID: <20300.16537.700270.474085@oracle.com> Bengt Rutisson (bengt.rutisson at oracle.com) wrote: > > Hi all, > > Just pinging this review request. Does anybody have some time to look at > it? It is a fairly small and straight forward change... Semantically looks ok. Some style issues, though. cardTableRS.cpp: --------------- I'd rather see the loop on 207 rewritten as: 207 while (cur_row >= limit && 208 *((intptr_t*)cur_row) == CardTableRS::clean_card_row()) { 209 cur_row -= BytesPerWord; 210 } as it's shorter and eliminates the 'break'. There are also whitespace problems (inconsistent indentation, 4 spaces instead of 2, no space after while, etc.). The comment that starts with 'Reset the dirty window' is now in only one of the places that does the reset. And this comment: // Note that "cur_entry" leads "start_of_non_clean" in // its leftward excursion after this point // in the loop and, when we hit the left end of "mr", // will point off of the left end of the card-table // for "mr". } is in an odd position (no code follows it) and the 'after' should be changed to 'at'. But instead of changing the comments, the new behavior can be achieved with a single new hunk of code in do_MemRegion that keeps the comments relevant: --- cardTableRS.cpp.org +++ cardTableRS.cpp @@ -17,10 +17,22 @@ // "dirty" range accumulated so far. if (start_of_non_clean < end_of_non_clean) { const MemRegion mrd(start_of_non_clean, end_of_non_clean); _dirty_card_closure->do_MemRegion(mrd); } + + // fast forward through potential continuous range of clean cards + if (is_word_aligned(cur_entry)) { + jbyte* cur_row = cur_entry - BytesPerWord; + while (cur_row >= limit && + *((intptr_t*)cur_row) == CardTableRS::clean_card_row()) { + cur_row -= BytesPerWord; + } + cur_entry = cur_row + BytesPerWord; + cur_hw = _ct->addr_for(cur_row + BytesPerWord); + } + // Reset the dirty window, while continuing to look // for the next dirty card that will start a // new dirty window. end_of_non_clean = cur_hw; start_of_non_clean = cur_hw; I think it's easier to follow. cardTableRS.hpp: --------------- 48 // making this constants into inline methods kills performance for some reason 49 static intptr_t clean_card_row() { 50 return CardTableModRefBS::clean_card_row; 51 } The comment seems to warn against the very thing the code is doing. If the comment is accurate, it's fine to eliminate the method and use the enum directly. 53 static bool card_is_dirty_wrt_gen_iter(jbyte cv) { 54 return CardTableModRefBS::card_is_dirty_wrt_gen_iter(cv); This whitespace change looks spurios. -John > -------- Original Message -------- > Subject: Request for review (S): 7068625 Testing 8 bytes of card table > entries at a time speeds up card-scanning > Date: Tue, 21 Feb 2012 12:03:50 +0400 > From: Alexey Ragozin > To: hotspot-gc-dev at openjdk.java.net > CC: Bengt Rutisson > > > > Hi, > > I would like few volunteers to review changes for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625 > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/ > > > Change summary > For large heaps (I was focusing on 8GiB and above) it is common to have > long continuous ranges of clean cards. > Patch is introducing a short path for skipping ranges of clean cards > using word aligned memory access instead of byte aligned. > > Patch affects serial and CMS collectors. For CMS collector stride size > should be increase to see any performance gains (I was using > -XX:+UnlockDiagnosticVMOptions > -XX:ParGCCardsPerStrideChunk=4096) > > For testing I was mainly using synthetic benchmark randomly modifying > hash tables in heap, thus uniformly touching cards across heaps. > Average duration of young GC pause were used as KPI. > More details about testing can be found at > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html > Though article is referring jdk6, my resent tests with trunk jdk7 show > no difference. > I was also tested patch with real application (Oracle Coherence storage > node). > With 16GiB of heap and CMS/ParNew GC, enabling patch have shortened GC > pauses roughly in 2 times. > > Source code of benchmark used in test are available at > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench > Main class YoungGCPauseBenchmark > > Regards, > Alexey > From openjdk at sunnychan.hk Tue Feb 28 00:57:54 2012 From: openjdk at sunnychan.hk (Sunny Chan) Date: Tue, 28 Feb 2012 08:57:54 +0000 (UTC) Subject: JEP 141: Increase the Client VM's Default Heap Size References: <20120221234824.93D481637@eggemoggin.niobe.net> <4F44DF52.3060804@fh-landshut.de> Message-ID: Michael Bien writes: > > On 02/22/2012 12:48 AM, mark.reinhold at ... wrote: > > Posted: http://openjdk.java.net/jeps/141 > > > > - Mark > > > additional risks: > - JVM may not be able to start > - could contribute to the false impression that java requires a lot of > memory to run (JVMs usually don't like to give memory back to the OS > once its in use) > > best regards, > michael > The "JVM may not be able to start" risk is particularly important to think about. At work we uses Citrix on Windows Servers and Citrix tends to fragment the address space by defining DLL's base address at location which breaks up the 32bit address space - an example of the issue is specified here: http://support.citrix.com/article/CTX115868) We probably want an algorithm to try a lower default -Xmx value if there isn't a large continuous block available for -Xmx1G. From jon.masamitsu at oracle.com Tue Feb 28 08:15:21 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 28 Feb 2012 08:15:21 -0800 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: References: <20120221234824.93D481637@eggemoggin.niobe.net> <4F44DF52.3060804@fh-landshut.de> Message-ID: <4F4CFD99.1070102@oracle.com> Sunny, We've talked about the fallback position of trying to reserve less that the default (say, 1G). Would you want it all to be done silently? Or would you want some warning that your not getting the whole 1G? Or would you want a flag (yet another flag, ugh) that you turn on that would cause a warning? Jon On 02/28/12 00:57, Sunny Chan wrote: > Michael Bien writes: > >> On 02/22/2012 12:48 AM, mark.reinhold at ... wrote: >>> Posted: http://openjdk.java.net/jeps/141 >>> >>> - Mark >>> >> additional risks: >> - JVM may not be able to start >> - could contribute to the false impression that java requires a lot of >> memory to run (JVMs usually don't like to give memory back to the OS >> once its in use) >> >> best regards, >> michael >> > The "JVM may not be able to start" risk is particularly important to think > about. > > At work we uses Citrix on Windows Servers and Citrix tends to fragment the > address space by defining DLL's base address at location which breaks up the > 32bit address space - an example of the issue is specified here: > http://support.citrix.com/article/CTX115868) > > We probably want an algorithm to try a lower default -Xmx value if there isn't a > large continuous block available for -Xmx1G. > From dean.long at oracle.com Tue Feb 28 14:05:42 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 28 Feb 2012 14:05:42 -0800 Subject: review request for 7142641: -Xshared:on fails on ARM Message-ID: <4F4D4FB6.7050807@oracle.com> http://cr.openjdk.java.net/~dlong/7142641/webrev.0/ Summary of changes: 3 lines changed: 0 ins; 2 del; 1 mod; 5538 unchg The Class Data Sharing file is mapped "shared" on linux, which places extra constraints on which virtual address a file offset can use. This is to ensure consistency on certain platforms with aliasing caches. However as the CDS file is opened read-only, mapping it "shared" has no benefit and can cause the mmap to fail. The simplest fix is to change the mapping to "private". Tested on linux arm platform with aliasing cache. Installed CDS with -Xshare:dump then ran through some vm tests as a sanity check. This bug is on the 7u4 watch list. dl From daniel.daugherty at oracle.com Tue Feb 28 14:40:33 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Feb 2012 15:40:33 -0700 Subject: review request for 7142641: -Xshared:on fails on ARM In-Reply-To: <4F4D4FB6.7050807@oracle.com> References: <4F4D4FB6.7050807@oracle.com> Message-ID: <4F4D57E1.9050703@oracle.com> Dean, I'm confused... I thought mapping the read-only CDS archive pages as "shared" permits those pages to be shared by other java processes that are also using the CDS archive... Dan On 2/28/12 3:05 PM, Dean Long wrote: > http://cr.openjdk.java.net/~dlong/7142641/webrev.0/ > Summary of changes: 3 lines changed: 0 ins; 2 del; 1 mod; 5538 unchg > > The Class Data Sharing file is mapped "shared" on linux, which places > extra constraints on which virtual address a file offset can use. > This is to ensure consistency on certain platforms with aliasing > caches. However as the CDS file is opened read-only, mapping it > "shared" has no benefit and can cause the mmap to fail. The simplest > fix is to change the mapping to "private". > > Tested on linux arm platform with aliasing cache. Installed CDS with > -Xshare:dump then ran through some vm tests as a sanity check. > > This bug is on the 7u4 watch list. > > dl From dean.long at oracle.com Tue Feb 28 15:43:16 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 28 Feb 2012 15:43:16 -0800 Subject: review request for 7142641: -Xshared:on fails on ARM In-Reply-To: <4F4D57E1.9050703@oracle.com> References: <4F4D4FB6.7050807@oracle.com> <4F4D57E1.9050703@oracle.com> Message-ID: <4F4D6694.8020501@oracle.com> Hi Dan, yes, I was concerned about that as well. But MAP_SHARED isn't actually needed to share read-only pages. If you trace an app's startup using "strace" you can see that the dynamic linker maps shared libraries such as libc with MAP_PRIVATE. Multiple processes still share those pages through the page cache. Furthermore, the linux mmap implementation turns off the shared flag if the file was opened read-only (but unfortunately it turns off the flag only after enforcing the cache coloring constraints.) dl On 2/28/2012 2:40 PM, Daniel D. Daugherty wrote: > Dean, > > I'm confused... I thought mapping the read-only CDS archive pages as > "shared" permits those pages to be shared by other java processes that > are also using the CDS archive... > > Dan > > On 2/28/12 3:05 PM, Dean Long wrote: >> http://cr.openjdk.java.net/~dlong/7142641/webrev.0/ >> Summary of changes: 3 lines changed: 0 ins; 2 del; 1 mod; 5538 unchg >> >> The Class Data Sharing file is mapped "shared" on linux, which places >> extra constraints on which virtual address a file offset can use. >> This is to ensure consistency on certain platforms with aliasing >> caches. However as the CDS file is opened read-only, mapping it >> "shared" has no benefit and can cause the mmap to fail. The simplest >> fix is to change the mapping to "private". >> >> Tested on linux arm platform with aliasing cache. Installed CDS with >> -Xshare:dump then ran through some vm tests as a sanity check. >> >> This bug is on the 7u4 watch list. >> >> dl From daniel.daugherty at oracle.com Tue Feb 28 15:46:52 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Feb 2012 16:46:52 -0700 Subject: review request for 7142641: -Xshared:on fails on ARM In-Reply-To: <4F4D6694.8020501@oracle.com> References: <4F4D4FB6.7050807@oracle.com> <4F4D57E1.9050703@oracle.com> <4F4D6694.8020501@oracle.com> Message-ID: <4F4D676C.6020308@oracle.com> Wow! Ya learn something new every day! Thanks for the background info. And you can count me as a reviewer... Since change affects all Linuxes, you should move the bug to jvm/hotspot/runtime_cds... Dan On 2/28/12 4:43 PM, Dean Long wrote: > Hi Dan, > > yes, I was concerned about that as well. But MAP_SHARED isn't > actually needed to share read-only pages. If you trace an app's > startup using "strace" you can see that the dynamic linker maps shared > libraries such as libc with MAP_PRIVATE. Multiple processes still > share those pages through the page cache. Furthermore, the linux mmap > implementation turns off the shared flag if the file was opened > read-only (but unfortunately it turns off the flag only after > enforcing the cache coloring constraints.) > > dl > > On 2/28/2012 2:40 PM, Daniel D. Daugherty wrote: >> Dean, >> >> I'm confused... I thought mapping the read-only CDS archive pages as >> "shared" permits those pages to be shared by other java processes that >> are also using the CDS archive... >> >> Dan >> >> On 2/28/12 3:05 PM, Dean Long wrote: >>> http://cr.openjdk.java.net/~dlong/7142641/webrev.0/ >>> Summary of changes: 3 lines changed: 0 ins; 2 del; 1 mod; 5538 unchg >>> >>> The Class Data Sharing file is mapped "shared" on linux, which >>> places extra constraints on which virtual address a file offset can >>> use. This is to ensure consistency on certain platforms with >>> aliasing caches. However as the CDS file is opened read-only, >>> mapping it "shared" has no benefit and can cause the mmap to fail. >>> The simplest fix is to change the mapping to "private". >>> >>> Tested on linux arm platform with aliasing cache. Installed CDS >>> with -Xshare:dump then ran through some vm tests as a sanity check. >>> >>> This bug is on the 7u4 watch list. >>> >>> dl From mark.reinhold at oracle.com Tue Feb 28 16:01:09 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Feb 2012 16:01:09 -0800 (PST) Subject: JEP 144: Reduce GC Latency for Large Heaps Message-ID: <20120229000109.2149E616@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/144 - Mark From vitalyd at gmail.com Tue Feb 28 16:11:37 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 28 Feb 2012 19:11:37 -0500 Subject: JEP 144: Reduce GC Latency for Large Heaps In-Reply-To: <20120229000109.2149E616@eggemoggin.niobe.net> References: <20120229000109.2149E616@eggemoggin.niobe.net> Message-ID: This is great guys. Just curious, has any consideration been given to implementing something like Azul's read barriers to allow mostly pauseless GC with large heaps? Thanks Sent from my phone On Feb 28, 2012 7:03 PM, wrote: > Posted: http://openjdk.java.net/jeps/144 > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120228/f98d6bcb/attachment.html From todd at cloudera.com Tue Feb 28 16:18:25 2012 From: todd at cloudera.com (Todd Lipcon) Date: Tue, 28 Feb 2012 16:18:25 -0800 Subject: JEP 144: Reduce GC Latency for Large Heaps In-Reply-To: <20120229000109.2149E616@eggemoggin.niobe.net> References: <20120229000109.2149E616@eggemoggin.niobe.net> Message-ID: Hi Mark, G1 team, Do you have any plans to address either of the problems discussed in the thread "G1GC Full GCs" from January '11? To refresh/summarize, the problems were: 1) If the process is context-switched out during the "Other time" accounting, and this causes the "other time" to eclipse the pause time goal, then it will never again select any non-young regions for collection until the next full GC. http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2011-January/000781.html There's a simple patch linked above which solved this problem for my usecase. 2) If a region, at any time during its lifetime, overflows its fine rset accounting, it's easy for it to become uncollectable despite a very high garbage ratio: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2011-January/000785.html I worked on some patch for this but wasn't able to get good results in the day or two that I allotted. -Todd On Tue, Feb 28, 2012 at 4:01 PM, wrote: > Posted: http://openjdk.java.net/jeps/144 > > - Mark -- Todd Lipcon Software Engineer, Cloudera From david.holmes at oracle.com Tue Feb 28 16:58:25 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Feb 2012 10:58:25 +1000 Subject: review request for 7142641: -Xshared:on fails on ARM In-Reply-To: <4F4D6694.8020501@oracle.com> References: <4F4D4FB6.7050807@oracle.com> <4F4D57E1.9050703@oracle.com> <4F4D6694.8020501@oracle.com> Message-ID: <4F4D7831.9090106@oracle.com> On 29/02/2012 9:43 AM, Dean Long wrote: > yes, I was concerned about that as well. But MAP_SHARED isn't actually > needed to share read-only pages. If you trace an app's startup using > "strace" you can see that the dynamic linker maps shared libraries such > as libc with MAP_PRIVATE. Multiple processes still share those pages > through the page cache. Furthermore, the linux mmap implementation turns > off the shared flag if the file was opened read-only (but unfortunately > it turns off the flag only after enforcing the cache coloring constraints.) Man page indicates MAP_SHARED and MAP_PRIVATE only affect the behaviour of writable pages: --- The flags argument determines whether updates to the mapping are visible to other processes mapping the same region, and whether updates are carried through to the underlying file. This behavior is determined by including exactly one of the following values in flags: MAP_SHARED Share this mapping. Updates to the mapping are visible to other processes that map this file, and are carried through to the underlying file. The file may not actually be updated until msync(2) or munmap() is called. MAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region. --- So having a read-only page marked MAP_SHARED is pointless. So looks good to me. The same mistake is made in other code in the closed repo, plus in the same code in os_bsd.cpp & os_solaris.cpp, plus perfMemory_.cpp David ------ > > dl > > On 2/28/2012 2:40 PM, Daniel D. Daugherty wrote: >> Dean, >> >> I'm confused... I thought mapping the read-only CDS archive pages as >> "shared" permits those pages to be shared by other java processes that >> are also using the CDS archive... >> >> Dan >> >> On 2/28/12 3:05 PM, Dean Long wrote: >>> http://cr.openjdk.java.net/~dlong/7142641/webrev.0/ >>> Summary of changes: 3 lines changed: 0 ins; 2 del; 1 mod; 5538 unchg >>> >>> The Class Data Sharing file is mapped "shared" on linux, which places >>> extra constraints on which virtual address a file offset can use. >>> This is to ensure consistency on certain platforms with aliasing >>> caches. However as the CDS file is opened read-only, mapping it >>> "shared" has no benefit and can cause the mmap to fail. The simplest >>> fix is to change the mapping to "private". >>> >>> Tested on linux arm platform with aliasing cache. Installed CDS with >>> -Xshare:dump then ran through some vm tests as a sanity check. >>> >>> This bug is on the 7u4 watch list. >>> >>> dl From openjdk at sunnychan.hk Wed Feb 29 00:21:29 2012 From: openjdk at sunnychan.hk (Sunny Chan) Date: Wed, 29 Feb 2012 08:21:29 +0000 (UTC) Subject: JEP 141: Increase the Client VM's Default Heap Size References: <20120221234824.93D481637@eggemoggin.niobe.net> <4F44DF52.3060804@fh-landshut.de> <4F4CFD99.1070102@oracle.com> Message-ID: Jon Masamitsu writes: > > Sunny, > > We've talked about the fallback position of trying to reserve > less that the default (say, 1G). Would you want it all to be done > silently? Or would you want some warning that your > not getting the whole 1G? Or would you want a flag > (yet another flag, ugh) that you turn on that would cause > a warning? > > Jon I think others should chime in on this, but the way I think about this is that 32bit Client VM are most likely running GUI applications, and generally they don't see any error message you push out onto the console. So unless your warning is going to be a message box pop up, no one would ever notice until they hit OutOfMemoryError. If an application doesn't specify a Xmx or Xms value, it is really telling the JVM that it doesn't really care what the sizings of the heap are and they are hoping the default would work. So as long as the fall back position is well known and well defined (e.g. JVM will try 1G and then 512M, then it will fail with a helpful message), then I don't think it would cause too many problems. From jon.masamitsu at oracle.com Wed Feb 29 01:34:30 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 29 Feb 2012 01:34:30 -0800 Subject: JEP 141: Increase the Client VM's Default Heap Size In-Reply-To: References: <20120221234824.93D481637@eggemoggin.niobe.net> <4F44DF52.3060804@fh-landshut.de> <4F4CFD99.1070102@oracle.com> Message-ID: <4F4DF126.3080708@oracle.com> On 2/29/2012 12:21 AM, Sunny Chan wrote: > Jon Masamitsu writes: > >> Sunny, >> >> We've talked about the fallback position of trying to reserve >> less that the default (say, 1G). Would you want it all to be done >> silently? Or would you want some warning that your >> not getting the whole 1G? Or would you want a flag >> (yet another flag, ugh) that you turn on that would cause >> a warning? >> >> Jon > I think others should chime in on this, but the way I think about this > is that 32bit Client VM are most likely running GUI applications, and > generally they don't see any error message you push out onto the console. > So unless your warning is going to be a message box pop up, no one would > ever notice until they hit OutOfMemoryError. > > If an application doesn't specify a Xmx or Xms value, it is really > telling the JVM that it doesn't really care what the sizings of the heap > are and they are hoping the default would work. So as long as the fall back > position is well known and well defined (e.g. JVM will try 1G and then 512M, > then it will fail with a helpful message), then I don't think it would cause > too many problems. I'm inclined to think that for a significant number of users, not specifying Xmx and Xms means they have accommodated the default limits, maybe by modifying their code to work well within those limits. I'm thinking that the change should be advertised as an increase up to the 1G (say) but less if there is less available. That is, we can't guarantee that we'll be able to get 1G so no one should count on it. I think that if we cannot reserve the current Xmx, we should fail to initialize as we do today (I think that would offer the least surprise to current users). I guess that's pretty much what you're saying. I'd just be more clear on the disclaimer - "Don't depend on getting the larger heap size". Jon From tony.printezis at oracle.com Wed Feb 29 09:23:44 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 29 Feb 2012 12:23:44 -0500 Subject: JEP 144: Reduce GC Latency for Large Heaps In-Reply-To: References: <20120229000109.2149E616@eggemoggin.niobe.net> Message-ID: <4F4E5F20.5010309@oracle.com> Todd, I recently pushed a change that causes G1 to be more aggressive when choosing which old regions to collect during mixed GCs. I think it still needs a bit more fine-tuning but it's much better compared to what we had before which I admit it was sub-optimal and fiddly. It should address both issues you mentioned below. Tony On 02/28/2012 07:18 PM, Todd Lipcon wrote: > Hi Mark, G1 team, > > Do you have any plans to address either of the problems discussed in > the thread "G1GC Full GCs" from January '11? > > To refresh/summarize, the problems were: > 1) If the process is context-switched out during the "Other time" > accounting, and this causes the "other time" to eclipse the pause time > goal, then it will never again select any non-young regions for > collection until the next full GC. > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2011-January/000781.html > There's a simple patch linked above which solved this problem for my usecase. > > 2) If a region, at any time during its lifetime, overflows its fine > rset accounting, it's easy for it to become uncollectable despite a > very high garbage ratio: > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2011-January/000785.html > I worked on some patch for this but wasn't able to get good results in > the day or two that I allotted. > > -Todd > > On Tue, Feb 28, 2012 at 4:01 PM, wrote: >> Posted: http://openjdk.java.net/jeps/144 >> >> - Mark > > From dean.long at oracle.com Wed Feb 29 09:30:20 2012 From: dean.long at oracle.com (Dean Long) Date: Wed, 29 Feb 2012 09:30:20 -0800 Subject: review request for 7142641: -Xshared:on fails on ARM In-Reply-To: <4F4D676C.6020308@oracle.com> References: <4F4D4FB6.7050807@oracle.com> <4F4D57E1.9050703@oracle.com> <4F4D6694.8020501@oracle.com> <4F4D676C.6020308@oracle.com> Message-ID: <4F4E60AC.7070108@oracle.com> Dan and David, thanks for the reviews. On 2/28/2012 3:46 PM, Daniel D. Daugherty wrote: > Wow! Ya learn something new every day! > > Thanks for the background info. And you can count me as > a reviewer... > > Since change affects all Linuxes, you should move the > bug to jvm/hotspot/runtime_cds... > OK will do. dl > Dan > > On 2/28/12 4:43 PM, Dean Long wrote: >> Hi Dan, >> >> yes, I was concerned about that as well. But MAP_SHARED isn't >> actually needed to share read-only pages. If you trace an app's >> startup using "strace" you can see that the dynamic linker maps >> shared libraries such as libc with MAP_PRIVATE. Multiple processes >> still share those pages through the page cache. Furthermore, the >> linux mmap implementation turns off the shared flag if the file was >> opened read-only (but unfortunately it turns off the flag only after >> enforcing the cache coloring constraints.) >> >> dl >> >> On 2/28/2012 2:40 PM, Daniel D. Daugherty wrote: >>> Dean, >>> >>> I'm confused... I thought mapping the read-only CDS archive pages as >>> "shared" permits those pages to be shared by other java processes that >>> are also using the CDS archive... >>> >>> Dan >>> >>> On 2/28/12 3:05 PM, Dean Long wrote: >>>> http://cr.openjdk.java.net/~dlong/7142641/webrev.0/ >>>> Summary of changes: 3 lines changed: 0 ins; 2 del; 1 mod; 5538 >>>> unchg >>>> >>>> The Class Data Sharing file is mapped "shared" on linux, which >>>> places extra constraints on which virtual address a file offset can >>>> use. This is to ensure consistency on certain platforms with >>>> aliasing caches. However as the CDS file is opened read-only, >>>> mapping it "shared" has no benefit and can cause the mmap to fail. >>>> The simplest fix is to change the mapping to "private". >>>> >>>> Tested on linux arm platform with aliasing cache. Installed CDS >>>> with -Xshare:dump then ran through some vm tests as a sanity check. >>>> >>>> This bug is on the 7u4 watch list. >>>> >>>> dl From todd at cloudera.com Wed Feb 29 12:04:39 2012 From: todd at cloudera.com (Todd Lipcon) Date: Wed, 29 Feb 2012 12:04:39 -0800 Subject: JEP 144: Reduce GC Latency for Large Heaps In-Reply-To: <4F4E5F20.5010309@oracle.com> References: <20120229000109.2149E616@eggemoggin.niobe.net> <4F4E5F20.5010309@oracle.com> Message-ID: On Wed, Feb 29, 2012 at 9:23 AM, Tony Printezis wrote: > Todd, > > I recently pushed a change that causes G1 to be more aggressive when > choosing which old regions to collect during mixed GCs. I think it still > needs a bit more fine-tuning but it's much better compared to what we had > before which I admit it was sub-optimal and fiddly. It should address both > issues you mentioned below. > Thanks for the update, Tony. Are these fixes in the latest JDK7 releases? Or do I need to build from hg? (is there a snapshot/nightly build from hg I could try if the latter to avoid the pain of building myself?) -Todd -- Todd Lipcon Software Engineer, Cloudera From tony.printezis at oracle.com Wed Feb 29 12:14:35 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 29 Feb 2012 15:14:35 -0500 Subject: JEP 144: Reduce GC Latency for Large Heaps In-Reply-To: References: <20120229000109.2149E616@eggemoggin.niobe.net> <4F4E5F20.5010309@oracle.com> Message-ID: <4F4E872B.60803@oracle.com> Todd, The fix should be on all the open repos by now and should also be included in the upcoming 7u4 release (i.e., it's in hotspot 23). Tony On 02/29/2012 03:04 PM, Todd Lipcon wrote: > On Wed, Feb 29, 2012 at 9:23 AM, Tony Printezis > wrote: >> Todd, >> >> I recently pushed a change that causes G1 to be more aggressive when >> choosing which old regions to collect during mixed GCs. I think it still >> needs a bit more fine-tuning but it's much better compared to what we had >> before which I admit it was sub-optimal and fiddly. It should address both >> issues you mentioned below. >> > Thanks for the update, Tony. Are these fixes in the latest JDK7 > releases? Or do I need to build from hg? (is there a snapshot/nightly > build from hg I could try if the latter to avoid the pain of building > myself?) > > -Todd From John.Coomes at oracle.com Wed Feb 29 18:20:30 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 29 Feb 2012 18:20:30 -0800 Subject: JEP 144: Reduce GC Latency for Large Heaps In-Reply-To: <4F4E872B.60803@oracle.com> References: <20120229000109.2149E616@eggemoggin.niobe.net> <4F4E5F20.5010309@oracle.com> <4F4E872B.60803@oracle.com> Message-ID: <20302.56558.925209.813709@oracle.com> Tony Printezis (tony.printezis at oracle.com) wrote: > Todd, > > The fix should be on all the open repos by now and should also be > included in the upcoming 7u4 release (i.e., it's in hotspot 23). FWIW, it's in the jdk8 snapshot build that's now on java.net: http://jdk8.java.net/download.html -John > On 02/29/2012 03:04 PM, Todd Lipcon wrote: > > On Wed, Feb 29, 2012 at 9:23 AM, Tony Printezis > > wrote: > >> Todd, > >> > >> I recently pushed a change that causes G1 to be more aggressive when > >> choosing which old regions to collect during mixed GCs. I think it still > >> needs a bit more fine-tuning but it's much better compared to what we had > >> before which I admit it was sub-optimal and fiddly. It should address both > >> issues you mentioned below. > >> > > Thanks for the update, Tony. Are these fixes in the latest JDK7 > > releases? Or do I need to build from hg? (is there a snapshot/nightly > > build from hg I could try if the latter to avoid the pain of building > > myself?) > > > > -Todd From chengtao.fh at taobao.com Wed Feb 29 19:50:28 2012 From: chengtao.fh at taobao.com (=?gb2312?B?s8nMzw==?=) Date: Thu, 1 Mar 2012 03:50:28 +0000 Subject: Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning Message-ID: I did some testing with id=7068625??s patch. Sun6u25 with hotspot20 VS Sun6u25 with hotspot20+patch, the results show as follow. 1. Special case I designed a special example, creating 30 large arrayes of 500 m. Because of the small young gen(384m), these arrays will be allocated in the old gen. Then i create many small objects, leading to frequently young gc. The result shows as follows, young gc performance improves 5 times. ?? 1st,YGC(s) 2nd,YGC(s) 3rd,YGC(s) Average,YGC(s) Sun6u25 , Hotspot20 19.5393 19.6194 19.6167 19.5918 Sun6u25,Hotspot20 with patch, ParGCCardsPerStrideChunk=4096 2.89477 2.85132 2.60825 2.78478 Jvm options is: -Xmn384m -Xss20m -Xms16g -Xmx16g -XX:PermSize=96m -XX:MaxPermSize=256m -XX:SurvivorRatio=10 -XX:VMThreadStackSize=30720 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -verbose:gc -Xloggc:log/test.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseCompressedOops -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=4096 2. GCbench I download GCBench.java from http://code.google.com/p/hotpy/source/browse/trunk/benchmarks/java/GCBench.java, and change kStretchTreeDepth = 25, kLongLivedTreeDepth = 22, kMaxTreeDepth = 25; the result shows as follows ?? 1st,YGC(s) 2nd,YGC(s) 3rd,YGC(s) Average,YGC(s) Sun6u25 , Hotspot20 1.15687 1.15133 1.14496 1.1510533 Sun6u25,Hotspot20 with patch, ParGCCardsPerStrideChunk =64 1.16177 1.16077 1.17036 1.1643 Sun6u25,Hotspot20 with patch, ParGCCardsPerStrideChunk =128 1.15831 1.17001 1.16075 1.1630233 Sun6u25,Hotspot20 with patch, ParGCCardsPerStrideChunk =256 1.14909 1.15332 1.15261 1.1516733 Sun6u25,Hotspot20 with patch, ParGCCardsPerStrideChunk =512 1.13964 1.14849 1.15045 1.1461933 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =1024 1.14355 1.15015 1.13443 1.14271 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =2048 1.13742 1.14496 1.14833 1.14357 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =4096 1.14581 1.14538 1.13679 1.14266 Jvm options is: ?CXmn2560m -Xss20m ?CXms4g ?CXmx4g -XX:PermSize=96m -XX:MaxPermSize=256m -XX:SurvivorRatio=10 -XX:VMThreadStackSize=30720 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -verbose:gc -Xloggc:log/test.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseCompressedOops 3. Specjvm2008 SPECJVM2008?? result shows as follow ?? 1st,YGC(s) 2nd,YGC(s) 3rd,YGC(s) Average,YGC(s) Sun6u25 , Hotspot20 9.76089 ??no test ??no test 9.76089 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =256 9.98591 9.48948 10.0271 9.8341633 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =4096 9.11581 9.18337 9.30351 9.2008967 Jvm options is: -Xmn2560m -Xss20m -Xms4g -Xmx4g -XX:PermSize=96m -XX:MaxPermSize=256m -XX:SurvivorRatio=10 -XX:VMThreadStackSize=30720 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -verbose:gc -Xloggc:log/test.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseCompressedOops -jar SPECjvm2008.jar -ikv --lagom -bt 8 -ops 15 -i 5 -pf props/specjvm.properties 4. Specjbb2005 Specjbb2005??s result shows as follow ?? 1st,YGC(s) 2nd,YGC(s) 3rd,YGC(s) Average,YGC(s) Sun6u25 , Hotspot20 97.5287 ??no test ??no test 97.5287 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =256 96.8332 96.6885 98.348 97.2899 Sun6u25,Hotspot20 with patch,ParGCCardsPerStrideChunk =4096 96.1914 96.3589 97.6005 96.716933 Jvm options is: -Xmn2560m -Xss20m -Xms4g -Xmx4g -XX:PermSize=96m -XX:MaxPermSize=256m -XX:SurvivorRatio=10 -XX:VMThreadStackSize=30720 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -verbose:gc -Xloggc:log/test.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseCompressedOops pec.jbb.JBBmain -propfile SPECjbb.props Summary 1. if a large heap is allocated in Old Gen and there are no or very few references from Old Gen to Young Gen, the patch improves gc performance a lot. 2. Generally, Such as GCbench, SPECJVM2008 and specjbb2005, the patch improves a little with proper ParGCCardsPerStrideChunk, but maybe bad a little with improper ParGCCardsPerStrideChunk. 3. this patch maybe is effective to app which allocates big heap and old gen is big Regards, Chengtao ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120301/6b87e2ca/attachment-0001.html