From y.s.ramakrishna at sun.com Wed Sep 2 02:16:25 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Wed, 02 Sep 2009 09:16:25 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 4957990: Perm heap bloat in JVM Message-ID: <20090902091632.7BE6712A13@hg.openjdk.java.net> Changeset: 8b46c4d82093 Author: ysr Date: 2009-09-02 00:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8b46c4d82093 4957990: Perm heap bloat in JVM Summary: Treat ProfileData in MDO's as a source of weak, not strong, roots. Fixes the bug for stop-world collection -- the case of concurrent collection will be fixed separately. Reviewed-by: jcoomes, jmasa, kvn, never ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp From antonios.printezis at sun.com Wed Sep 2 04:36:27 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Wed, 02 Sep 2009 11:36:27 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6819085: G1: use larger and/or user settable region size Message-ID: <20090902113634.713E512A30@hg.openjdk.java.net> Changeset: 2c79770d1f6e Author: tonyp Date: 2009-07-30 16:22 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2c79770d1f6e 6819085: G1: use larger and/or user settable region size Summary: Instead of the region size being hard-coded, allow the user to set it. Reviewed-by: jmasa, johnc, apetrusenko ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 From guanxiaohua at gmail.com Wed Sep 2 11:47:22 2009 From: guanxiaohua at gmail.com (Tony Guan) Date: Wed, 2 Sep 2009 13:47:22 -0500 Subject: capturing method entry/exit efficiently Message-ID: <2fcb552b0909021147r4a9425dds961bf020cb8ee4a4@mail.gmail.com> Dear all, One update for yesterday's mail is that I am now able to add some call_vm() code in TemplateTable::invokespecial(), to get my own code executed. This is much economy in compared with JVMTI. But I just cannot find a suitable place for monitoring the method_exit. Any idea about that? And still, the compiled method is still a nightmare for me. Thanks! Tony > Dear all, > > My current research project with hotspot requires me to do something > particular whenever a method(interpreted or compiled) is invoked. I > need to know the thread and the method at the invocation time. What I > am trying to do is to do some VM hacking based on the methods called. > Question 1: Can I use BCI to achieve this? > > I am now able to capture the method_entry/exit events by writing a > JVMTI agent, but it's not what I really need to do. By using JVMTI, > performance is deteriorated a lot. And I am not sure if the compiled > method can still be captured. (Though I know java1.5 has some JVMPI > support in the compilation part, but not in java1.7. Am I right?). > Question 2: I am trying find a way to enable the > notify_method_enry/exit by partly simulating an JVMTI agent, that > means that I modify several parts in the hotspot without actually use > an external JVMTI agent. Is it feasible? (in terms of perfomance) > > Question 3: Is there some better way to capture the method_entry/exit event? > > Thanks for diluting the question marks in my mind! > > Tony ?(Xiaohua Guan) > > > ------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > > End of hotspot-gc-use Digest, Vol 21, Issue 1 > ********************************************* > -- Xiaohua Guan (Tony) Department of Computer Science and Engineering University of Nebraska-Lincoln 103A Avery Hall Lincoln, NE 68588-0115 Tel: 402-472-3884 Email: xguan at cse.unl.edu URL: http://www.cse.unl.edu/~xguan (This email is encoded as Unicode(UTF-8)) _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Peter.Kessler at Sun.COM Thu Sep 3 10:47:23 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Thu, 03 Sep 2009 10:47:23 -0700 Subject: capturing method entry/exit efficiently In-Reply-To: <2fcb552b0909021147r4a9425dds961bf020cb8ee4a4@mail.gmail.com> References: <2fcb552b0909021147r4a9425dds961bf020cb8ee4a4@mail.gmail.com> Message-ID: <4AA0012B.2090509@Sun.COM> Since hotspot-gc-use at openjdk.java.net is the HotSpot GC users mailing list, you might not be reaching the people who can help you with your project. I would suggest asking on the hotspot-runtime-dev at openjdk-java.net for help with the interpreter (e.g., TemplateTable), or hotspot-compiler-dev at openjdk.java.net for help with the runtime compiler, or serviceability-dev at openjdk.java.net for help with the monitoring frameworks (e.g., JVMTI). But the garbage collectors don't have anything to do with method entry or exit. You might also want to look at bytecode rewriting, e.g., via your own classloader, to add instrumentation to method entries and exits for the methods of the classes you are interested in. I think there are tools available that make bytecode rewriting not as difficult as it sounds. ... peter Tony Guan wrote: > Dear all, > > One update for yesterday's mail is that I am now able to add some > call_vm() code in TemplateTable::invokespecial(), to get my own code > executed. This is much economy in compared with JVMTI. But I just > cannot find a suitable place for monitoring the method_exit. > > Any idea about that? And still, the compiled method is still a nightmare for me. > > Thanks! > > Tony > >> Dear all, >> >> My current research project with hotspot requires me to do something >> particular whenever a method(interpreted or compiled) is invoked. I >> need to know the thread and the method at the invocation time. What I >> am trying to do is to do some VM hacking based on the methods called. >> Question 1: Can I use BCI to achieve this? >> >> I am now able to capture the method_entry/exit events by writing a >> JVMTI agent, but it's not what I really need to do. By using JVMTI, >> performance is deteriorated a lot. And I am not sure if the compiled >> method can still be captured. (Though I know java1.5 has some JVMPI >> support in the compilation part, but not in java1.7. Am I right?). >> Question 2: I am trying find a way to enable the >> notify_method_enry/exit by partly simulating an JVMTI agent, that >> means that I modify several parts in the hotspot without actually use >> an external JVMTI agent. Is it feasible? (in terms of perfomance) >> >> Question 3: Is there some better way to capture the method_entry/exit event? >> >> Thanks for diluting the question marks in my mind! >> >> Tony (Xiaohua Guan) >> >> >> ------------------------------ >> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> >> End of hotspot-gc-use Digest, Vol 21, Issue 1 >> ********************************************* >> > > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at sun.com Thu Sep 3 22:55:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 05:55:21 +0000 Subject: hg: jdk7/hotspot-gc: 3 new changesets Message-ID: <20090904055521.6D23A12B9F@hg.openjdk.java.net> Changeset: d8b49b53d8cf Author: wetmore Date: 2009-08-14 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/d8b49b53d8cf 6872177: JCE framework and provider builds broken following -target 7 changes Reviewed-by: ohair ! make/Defs-internal.gmk Changeset: 4c36e9853dda Author: tbell Date: 2009-08-24 22:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/4c36e9853dda Merge Changeset: 378f57273f09 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/378f57273f09 Added tag jdk7-b71 for changeset 4c36e9853dda ! .hgtags From john.coomes at sun.com Thu Sep 3 23:02:40 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 06:02:40 +0000 Subject: hg: jdk7/hotspot-gc/corba: 4 new changesets Message-ID: <20090904060244.59E6F12BA4@hg.openjdk.java.net> Changeset: 8001ba2bf10d Author: andrew Date: 2009-08-20 01:28 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/8001ba2bf10d 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: jjg, ohair ! make/common/shared/Defs-java.gmk Changeset: 04414f276160 Author: xdono Date: 2009-08-24 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/04414f276160 Merge Changeset: 3f1ef7f899ea Author: andrew Date: 2009-09-01 23:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/3f1ef7f899ea 6878106: Synchronize CORBA and JDK makefiles where possible Summary: Add recent changes to the JDK makefile to the CORBA makefile Reviewed-by: jjg, never ! make/common/shared/Defs-java.gmk Changeset: c793a3120926 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/c793a3120926 Added tag jdk7-b71 for changeset 3f1ef7f899ea ! .hgtags From john.coomes at sun.com Thu Sep 3 23:14:44 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 06:14:44 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b71 for changeset ff94d8ce0dad Message-ID: <20090904061447.BEA8B12BA9@hg.openjdk.java.net> Changeset: 37c805b6156f Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/37c805b6156f Added tag jdk7-b71 for changeset ff94d8ce0dad ! .hgtags From john.coomes at sun.com Thu Sep 3 23:22:33 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 06:22:33 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b71 for changeset 03314cf56a72 Message-ID: <20090904062236.49EC312BAE@hg.openjdk.java.net> Changeset: 4c990aa99bc0 Author: xdono Date: 2009-09-03 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/4c990aa99bc0 Added tag jdk7-b71 for changeset 03314cf56a72 ! .hgtags From john.coomes at sun.com Thu Sep 3 23:31:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 06:31:03 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 27 new changesets Message-ID: <20090904063824.6377712BB3@hg.openjdk.java.net> Changeset: 1ff977b938e5 Author: sherman Date: 2009-08-13 10:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1ff977b938e5 6840246: Lightweight implementation of String.split for simple use case Summary: Added a fastpath for simple use case Reviewed-by: alanb, martin ! src/share/classes/java/lang/String.java ! test/java/lang/String/Split.java Changeset: 8c0c96a3f9f6 Author: wetmore Date: 2009-08-13 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8c0c96a3f9f6 6870335: Provider numbers need to be bumped to 1.7 Reviewed-by: mullan ! src/share/classes/com/sun/security/sasl/Provider.java ! src/share/classes/sun/security/jgss/SunProvider.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/smartcardio/SunPCSC.java ! src/share/classes/sun/security/ssl/SunJSSE.java Changeset: 6797a2407a50 Author: wetmore Date: 2009-08-13 12:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6797a2407a50 Merge Changeset: 35f32639ee20 Author: sherman Date: 2009-08-13 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/35f32639ee20 6676423: (prefs) Opensource unit/regression tests for java.util.prefs Summary: Moved the existing test cases for prefs to open area Reviewed-by: martin, alanb + test/java/util/prefs/CommentsInXml.java + test/java/util/prefs/ConflictInFlush.java + test/java/util/prefs/ExportNode.java + test/java/util/prefs/ExportSubtree.java + test/java/util/prefs/PrefsSpi.java + test/java/util/prefs/PrefsSpi.sh + test/java/util/prefs/RemoveReadOnlyNode.java + test/java/util/prefs/RemoveUnregedListener.java + test/java/util/prefs/SerializeExceptions.java Changeset: f094eb92a6e0 Author: sherman Date: 2009-08-13 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f094eb92a6e0 Merge Changeset: 7fcdefc99dc4 Author: sherman Date: 2009-08-14 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7fcdefc99dc4 6866397: (file) PathMatcher with regex syntax doesn't match as expected (win) Summary: Use unicode_case_insensitive for windows path matcher for now. Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! test/java/nio/file/PathMatcher/Basic.java Changeset: 77a1c2056565 Author: sherman Date: 2009-08-14 14:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/77a1c2056565 6730652: CharsetEncoder.canEncode(char) returns incorrect values for some charsets Summary: override the canEncode() in ISO2022_CN_CNS Reviewed-by: martin ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_CN_CNS.java ! test/sun/nio/cs/FindCanEncodeBugs.java Changeset: 8414927b41d8 Author: weijun Date: 2009-08-18 10:20 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8414927b41d8 6829785: TextCallbackHandler does not honor PasswordCallback.isEchoOn() Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java ! src/share/classes/sun/security/util/Password.java + test/com/sun/security/auth/callback/TextCallbackHandler/Password.java Changeset: 74029d1cf4e4 Author: tbell Date: 2009-08-18 17:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/74029d1cf4e4 Merge Changeset: 5e8986cabdd8 Author: weijun Date: 2009-08-20 11:24 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5e8986cabdd8 6867665: Problem with keytabs with multiple kvno's (key versions) Reviewed-by: valeriep, ohair ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/ktab/HighestKvno.java Changeset: dfece53c600f Author: alanb Date: 2009-08-20 08:39 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dfece53c600f 6595866: File does work with symbolic links (win,vista) Reviewed-by: sherman ! src/windows/native/java/io/WinNTFileSystem_md.c + test/java/io/File/SymLinks.java Changeset: 70c03e494a68 Author: alanb Date: 2009-08-20 08:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/70c03e494a68 6870926: (file) Path.toRealPath performance can be improved (win) Reviewed-by: sherman ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsLinkSupport.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 5cd12b68d09b Author: alanb Date: 2009-08-20 08:48 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5cd12b68d09b 6866804: (file) Path calls checkPermission insteadof checkXXX (sol) Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java + test/java/nio/file/Path/CheckPermissions.java ! test/java/nio/file/Path/Misc.java Changeset: 3992a43bb0a5 Author: darcy Date: 2009-08-21 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3992a43bb0a5 6378701: (enum) Unclear purpose of EnumConstantNotPresentException Reviewed-by: lancea, andrew, alanb ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/TypeNotPresentException.java ! src/share/classes/java/lang/annotation/AnnotationFormatError.java ! src/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java Changeset: 99a55f6f1cef Author: alanb Date: 2009-08-22 17:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/99a55f6f1cef 6874521: Remove @note tags Reviewed-by: andrew, darcy ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/util/Scanner.java Changeset: cef30252932a Author: alanb Date: 2009-08-23 12:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cef30252932a 6842687: New I/O: Update Asynchronous I/O API to jsr203/nio2-b101 Reviewed-by: sherman ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/channels/AsynchronousByteChannel.java ! src/share/classes/java/nio/channels/AsynchronousChannel.java ! src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/CompletionHandler.java ! src/share/classes/java/nio/channels/exceptions - src/share/classes/sun/nio/ch/AbstractFuture.java ! src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java ! src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/Invoker.java ! src/share/classes/sun/nio/ch/PendingFuture.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/native/sun/nio/ch/Iocp.c ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java ! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java + test/java/nio/channels/AsynchronousSocketChannel/DieBeforeComplete.java ! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java Changeset: fca3e1a178fd Author: alanb Date: 2009-08-23 17:20 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fca3e1a178fd Merge Changeset: dbcc1f13e4fd Author: weijun Date: 2009-08-24 18:37 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dbcc1f13e4fd 6875033: regression: test of 6867665 fail Reviewed-by: xuelei ! test/sun/security/krb5/ktab/HighestKvno.java Changeset: d954cd279188 Author: ohair Date: 2009-08-24 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d954cd279188 6853636: Fix warnings in jdwpgen, add jdwpgen NetBeans project Reviewed-by: andrew, alanb, tbell, swamyv ! .hgignore + make/netbeans/jdwpgen/build.xml + make/netbeans/jdwpgen/nbproject/build-impl.xml + make/netbeans/jdwpgen/nbproject/findbugs.settings + make/netbeans/jdwpgen/nbproject/genfiles.properties + make/netbeans/jdwpgen/nbproject/project.properties + make/netbeans/jdwpgen/nbproject/project.xml + make/netbeans/jdwpgen/nbproject/sqe.properties ! make/tools/src/build/tools/jdwpgen/AbstractNamedNode.java ! make/tools/src/build/tools/jdwpgen/AltNode.java ! make/tools/src/build/tools/jdwpgen/ConstantSetNode.java ! make/tools/src/build/tools/jdwpgen/Main.java ! make/tools/src/build/tools/jdwpgen/Node.java ! make/tools/src/build/tools/jdwpgen/Parse.java ! make/tools/src/build/tools/jdwpgen/RepeatNode.java ! make/tools/src/build/tools/jdwpgen/SelectNode.java Changeset: dd997cc0c823 Author: vinnie Date: 2009-08-24 18:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dd997cc0c823 6872048: bad private keys are generated for 2 specific ECC curves Reviewed-by: wetmore ! src/share/native/sun/security/ec/ec.c ! test/sun/security/ec/TestEC.java Changeset: b71a03c75515 Author: tbell Date: 2009-08-24 22:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b71a03c75515 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: 80368890a2a0 Author: andrew Date: 2009-08-18 19:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/80368890a2a0 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: 43465920bf47 Author: xdono Date: 2009-08-18 19:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/43465920bf47 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: b3aac0db5586 Author: tbell Date: 2009-08-21 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b3aac0db5586 6705913: freetype_versioncheck.exe - Unable To Locate Component Summary: Update freetype_versioncheck to deal with newer Visual Studio releases Reviewed-by: ohair ! make/tools/freetypecheck/Makefile ! make/tools/freetypecheck/freetypecheck.c Changeset: e0b26d347302 Author: xdono Date: 2009-08-24 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e0b26d347302 Merge Changeset: b3f3240135f0 Author: xdono Date: 2009-09-01 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b3f3240135f0 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java Changeset: ce3fde68c495 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ce3fde68c495 Added tag jdk7-b71 for changeset b3f3240135f0 ! .hgtags From john.coomes at sun.com Thu Sep 3 23:52:58 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 04 Sep 2009 06:52:58 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 11 new changesets Message-ID: <20090904065318.B103A12BC3@hg.openjdk.java.net> Changeset: 8a03f3c7d160 Author: jjg Date: 2009-08-12 07:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8a03f3c7d160 6870706: langtools launcher issues Reviewed-by: mcimadamore ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 71680973d8ec Author: jjg Date: 2009-08-12 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/71680973d8ec 6758471: should be able to set jtreg options in langtools build Reviewed-by: mcimadamore ! make/build.properties ! make/build.xml Changeset: 7dbb79875a63 Author: jjg Date: 2009-08-12 10:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/7dbb79875a63 6558476: com/sun/tools/javac/Main.compile don't release file handles on return Reviewed-by: darcy + src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/T6558476.java Changeset: b055a5ea0dad Author: tbell Date: 2009-08-18 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/b055a5ea0dad Merge Changeset: 2aa3a1cdb094 Author: andrew Date: 2009-08-19 20:44 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2aa3a1cdb094 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: Set source and target explicitly in pcompile task Reviewed-by: jjg ! make/build.xml Changeset: 2ce3597237f0 Author: darcy Date: 2009-08-19 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2ce3597237f0 6871291: Please clarify javax.tools.JavaCompiler.getTask() "classes" parameter Reviewed-by: jjg ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 61c1f735df67 Author: jjg Date: 2009-08-21 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/61c1f735df67 6873849: suppress notes generated by javac Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/T6873849.java Changeset: d9febdd5ae21 Author: jjg Date: 2009-08-21 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d9febdd5ae21 6873845: refine access to symbol file Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/T6873845.java Changeset: c863e90091ee Author: jjg Date: 2009-08-24 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/c863e90091ee 6869216: testgetallmembers should consistently use correct filemanager Reviewed-by: darcy ! test/tools/javac/processing/model/testgetallmembers/Main.java Changeset: 33c8c38e1757 Author: tbell Date: 2009-08-24 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/33c8c38e1757 Merge Changeset: d434aa041b52 Author: xdono Date: 2009-09-03 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d434aa041b52 Added tag jdk7-b71 for changeset 33c8c38e1757 ! .hgtags From andrey.petrusenko at sun.com Fri Sep 4 12:31:17 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 04 Sep 2009 19:31:17 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 31 new changesets Message-ID: <20090904193221.3609E12C8E@hg.openjdk.java.net> Changeset: d07e68298d4e Author: xdono Date: 2009-07-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d07e68298d4e Added tag jdk7-b67 for changeset 18f526145aea ! .hgtags Changeset: 54fd4d923296 Author: xdono Date: 2009-08-06 10:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/54fd4d923296 Added tag jdk7-b68 for changeset d07e68298d4e ! .hgtags Changeset: 5021b9893d0a Author: xdono Date: 2009-08-13 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5021b9893d0a Added tag jdk7-b69 for changeset 54fd4d923296 ! .hgtags Changeset: f753dffae23e Author: trims Date: 2009-08-13 17:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f753dffae23e 6871765: Bump the HS16 build number to 08 Summary: Update the HS16 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 16314a31b961 Author: trims Date: 2009-08-13 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/16314a31b961 Merge Changeset: ac59d4e6dae5 Author: trims Date: 2009-08-14 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ac59d4e6dae5 Merge Changeset: 1760a1cbed36 Author: dcubed Date: 2009-08-11 11:57 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1760a1cbed36 6862945: 4/3 conversion of jmethodID to methodOop in JVMTI is too expensive Summary: Refactor JNIHandles::checked_resolve_jmethod_id() into fast and paranoid parts. Reviewed-by: never, alanb ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/runtime/jniHandles.hpp Changeset: 6ab1d6ece8bd Author: apangin Date: 2009-08-17 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6ab1d6ece8bd Merge Changeset: 585222cadf79 Author: apangin Date: 2009-08-19 15:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/585222cadf79 Merge Changeset: 185d256992c3 Author: asaha Date: 2009-08-07 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/185d256992c3 6803688: Integrate latest JAX-WS (2.1.6) in to JDK 6u14 Reviewed-by: darcy, ramap ! THIRD_PARTY_README Changeset: adba5b333f26 Author: asaha Date: 2009-08-10 10:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/adba5b333f26 Merge Changeset: 0632c3e615a3 Author: tbell Date: 2009-08-14 08:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0632c3e615a3 Merge Changeset: 50a704b1d838 Author: xdono Date: 2009-08-20 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/50a704b1d838 Added tag jdk7-b70 for changeset 0632c3e615a3 ! .hgtags Changeset: 50a95aa4a247 Author: trims Date: 2009-08-21 20:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/50a95aa4a247 Merge Changeset: a05ea7791ee3 Author: trims Date: 2009-08-21 20:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a05ea7791ee3 6873236: Fork HS16 to HS17 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS17 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: a774e1abbe85 Author: trims Date: 2009-08-21 20:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a774e1abbe85 Merge Changeset: 046932b72aa2 Author: never Date: 2009-08-14 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/046932b72aa2 6862956: PhaseIdealLoop should have a CFG verification mode Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp Changeset: 1a81ea4b45d4 Author: kvn Date: 2009-08-14 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1a81ea4b45d4 6869822: assert(Universe::narrow_oop_shift() == 0,"use unscaled narrow oop") Summary: Replace the assert with narrow_oop_shift set to 0. Reviewed-by: never, jcoomes ! src/share/vm/memory/universe.cpp Changeset: a70508bb21c3 Author: never Date: 2009-08-14 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a70508bb21c3 6862863: C2 compiler fails in elide_copy() Reviewed-by: kvn ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: 55784fd95fe3 Author: never Date: 2009-08-14 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/55784fd95fe3 Merge Changeset: 7c14587118b3 Author: never Date: 2009-08-14 22:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7c14587118b3 Merge Changeset: c8e2135f7e30 Author: cfang Date: 2009-08-17 09:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c8e2135f7e30 6829127: Deoptimization Failure on Specjvm98 _227_mtrt with -XX:+DeoptimizeALot since Hs11 b01 Summary: Make sure the control word is correct in deopt_blob after restore_result_registers Reviewed-by: kvn, never ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp Changeset: 662f330d7275 Author: cfang Date: 2009-08-17 12:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/662f330d7275 6866651: Regression: simple int sum crashes jvm (build 1.6.0_14-b08 and 1.7.0-ea-b59) Summary: delay dead code elimination in set_req_X to make it safe Reviewed-by: kvn, never ! src/share/vm/opto/phaseX.cpp + test/compiler/6866651/Test.java Changeset: d0acbc302e14 Author: never Date: 2009-08-17 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d0acbc302e14 6795465: Crash in assembler_sparc.cpp with client compiler on solaris-sparc Reviewed-by: twisti, cfang ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/share/vm/includeDB_compiler1 + test/compiler/6795465/Test6795465.java Changeset: cd18bd5e667c Author: never Date: 2009-08-19 18:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cd18bd5e667c 6873777: FPU control word optimization still performed with SSE Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 357d4e2eb4dd Author: kvn Date: 2009-08-19 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/357d4e2eb4dd 6873799: enable escape analysis by default Summary: enable escape analysis by default Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp Changeset: 72088be4b386 Author: cfang Date: 2009-08-20 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/72088be4b386 6873116: Modify reexecute implementation to use pcDesc to record the reexecute bit Summary: use PcDesc to keep record of the reexecute bit instead of using DebugInfoStreams Reviewed-by: kvn, never, twisti ! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/code/PCDesc.java ! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 82bd76d4d7f2 Author: kvn Date: 2009-08-24 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/82bd76d4d7f2 6873800: enable compressed oops by default Summary: enable compressed oops by default Reviewed-by: never, ysr ! src/share/vm/runtime/arguments.cpp Changeset: cdb8b7c37ac1 Author: never Date: 2009-08-24 22:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cdb8b7c37ac1 6875329: fix for 6795465 broke exception handler cloning Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: aba04734b61e Author: kvn Date: 2009-08-25 13:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/aba04734b61e Merge Changeset: b1606b3c0a8a Author: apetrusenko Date: 2009-09-04 05:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b1606b3c0a8a Merge ! src/share/vm/code/nmethod.cpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp From John.Rose at Sun.COM Tue Sep 8 01:38:39 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 01:38:39 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> Message-ID: I have sufficient reviews for 6863023 as of webrev.03, but the GC interactions are (sigh) more subtle than I anticipated, and I want to get it right. Here is a fresh layer of changes, required to ensure that strong-root nmethods get scavenged exactly once. http://cr.openjdk.java.net/~jrose/6863023/diff-02-to-03 (these specific changes) http://cr.openjdk.java.net/~jrose/6863023/webrev.03 (full webrev) These changes fix some double-tracing bugs, but they are not correct. However, they are not right yet. What I'm asking for now is (a) further advice for structuring the nmethod-walking code correctly, and (b) help spotting bugs. -- John From Y.S.Ramakrishna at Sun.COM Tue Sep 8 12:19:57 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 08 Sep 2009 12:19:57 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> Message-ID: <4AA6AE5D.206@Sun.COM> Hi John -- On 09/08/09 01:38, John Rose wrote: > I have sufficient reviews for 6863023 as of webrev.03, but the GC > interactions are (sigh) more subtle than I anticipated, and I want to > get it right. > > Here is a fresh layer of changes, required to ensure that strong-root > nmethods get scavenged exactly once. > http://cr.openjdk.java.net/~jrose/6863023/diff-02-to-03 (these > specific changes) I looked at the above and the changes look fine to me. I had a question about the # of active nmethods that get thus linked into your marked list. Is this a fairly small number? Or fairly large? If large, then perhaps an alternative implementation might be worth considering where each worker thread maintains its own local list (head) to which it links the just claimed nmethod rather than to the single global list. This would reduce contention for a global head and would avoid one CAS per nmethod claimed. Then, in the epilogue (which would have to be appropriately sited in the per-worker marking code), the workers could run down their local lists in parallel, thus avoiding a serial bottlebeck. As I said, it depends on the expected volume of these active nmethods. Perhaps they are sufficiently small (even as # active threads in the application scales up) for this not to become a scalability issue in the future? > http://cr.openjdk.java.net/~jrose/6863023/webrev.03 (full webrev) > > These changes fix some double-tracing bugs, but they are not correct. > However, they are not right yet. What I'm asking for now is (a) further > advice for structuring the nmethod-walking code correctly, and (b) help > spotting bugs. Any hints on the kinds of bugs you may be seeing? My first overview of the structure of yr changes looks fine, but i will do a second, more careful, pass to see if i can spot any potential issues. later. -- ramki > > -- John From Y.S.Ramakrishna at Sun.COM Tue Sep 8 15:06:21 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 08 Sep 2009 15:06:21 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4AA6AE5D.206@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> <4AA6AE5D.206@Sun.COM> Message-ID: <4AA6D55D.4060901@Sun.COM> I've started looking at the entire webrev (the second of the two links you provided below). I am not done yet, but had two small comments: (1) the "DetectScavengeRoot" closure appears to check for the presence of any non-perm oop, whereas your interest is really in something that is in a space subject to a partial collection (i.e. a scavenge in our current collectors). So your current check is too loose and will often identify nmethods to have "scavengable" oops when in fact they do not (their references having moved into the old gen which is only collected during a full collection). I think you need to change the check:- 1651 virtual void do_oop(oop* p) { 1652 if ((*p) != NULL && !(*p)->is_perm()) { ^^^^^^^^^^^^^^^^ !(*p)->is_is_young()) or equivalent 1653 NOT_PRODUCT(maybe_print(p)); 1654 _detected_scavenge_root = true; 1655 } 1656 } (2) Could the removal of nmethods from the scavengable list following flush get potentially expensive as you walk down the list to find the appropriate nmethod (could the list get long, at least with large young gens and with certain kinds of dynamic language applications?). Would it be worthwhile to make this scavengable list doubly linked so as to allow constant time deletion? Depends on how frequently nmethod flushing occurs in the new world of scavengable oops in nmethods, i suppose... Next I'll go and check that the refs from the scavengable list of nmethods act (in general, unless activations are present), as weak roots, not strong roots (otherwise they would constitute a temporary "leak" until the references got promoted to the old generation, modulo my remark (1) above), but wanted to get these comments to you first. later. -- ramki On 09/08/09 12:19, Y.S.Ramakrishna at Sun.COM wrote: > > Hi John -- > > On 09/08/09 01:38, John Rose wrote: >> I have sufficient reviews for 6863023 as of webrev.03, but the GC >> interactions are (sigh) more subtle than I anticipated, and I want to >> get it right. >> >> Here is a fresh layer of changes, required to ensure that strong-root >> nmethods get scavenged exactly once. >> http://cr.openjdk.java.net/~jrose/6863023/diff-02-to-03 (these >> specific changes) > > I looked at the above and the changes look fine to me. I had a question > about the # of active nmethods that get thus linked into your marked > list. Is this a fairly small number? Or fairly large? > > If large, then perhaps an alternative implementation might be worth > considering where each worker thread maintains its own local list > (head) to which it links the just claimed nmethod rather than to the > single global list. This would reduce contention for a global head > and would avoid one CAS per nmethod claimed. > Then, in the epilogue (which would have to be appropriately sited > in the per-worker marking code), the workers could run down their > local lists in parallel, thus avoiding a serial bottlebeck. > As I said, it depends on the expected volume of these active > nmethods. Perhaps they are sufficiently small (even as # active > threads in the application scales up) for this not to become > a scalability issue in the future? > >> http://cr.openjdk.java.net/~jrose/6863023/webrev.03 (full webrev) >> >> These changes fix some double-tracing bugs, but they are not correct. >> However, they are not right yet. What I'm asking for now is (a) >> further advice for structuring the nmethod-walking code correctly, and >> (b) help spotting bugs. > > Any hints on the kinds of bugs you may be seeing? My first overview of > the structure of yr changes looks fine, but i will do a second, more > careful, pass to see if i can spot any potential issues. > > later. > -- ramki > >> >> -- John > > From John.Rose at Sun.COM Tue Sep 8 15:23:42 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 15:23:42 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4AA6AE5D.206@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> <4AA6AE5D.206@Sun.COM> Message-ID: Responses below... -- John (on my iPhone) On Sep 8, 2009, at 12:19 PM, Y.S.Ramakrishna at Sun.COM wrote: > > Hi John -- > > On 09/08/09 01:38, John Rose wrote: >> I have sufficient reviews for 6863023 as of webrev.03, but the GC >> interactions are (sigh) more subtle than I anticipated, and I want >> to get it right. >> Here is a fresh layer of changes, required to ensure that strong- >> root nmethods get scavenged exactly once. >> http://cr.openjdk.java.net/~jrose/6863023/diff-02-to-03 (these >> specific changes) > > I looked at the above and the changes look fine to me. I had a > question > about the # of active nmethods that get thus linked into your marked > list. Is this a fairly small number? Or fairly large? It should be a small number compared to the number of scavenged objects. It is about one NM ref per live stack frame, and for many- threaded apps. there will be many repeat refs. > > If large, then perhaps an alternative implementation might be worth > considering where each worker thread maintains its own local list > (head) to which it links the just claimed nmethod rather than to the > single global list. This would reduce contention for a global head > and would avoid one CAS per nmethod claimed. > Then, in the epilogue (which would have to be appropriately sited > in the per-worker marking code), the workers could run down their > local lists in parallel, thus avoiding a serial bottlebeck. > As I said, it depends on the expected volume of these active > nmethods. Perhaps they are sufficiently small (even as # active > threads in the application scales up) for this not to become > a scalability issue in the future? Yes I think the number of queue events will be very small, rarely more than 1000. > >> http://cr.openjdk.java.net/~jrose/6863023/webrev.03 (full webrev) >> These changes fix some double-tracing bugs, but they are not >> correct. However, they are not right yet. What I'm asking for now >> is (a) further advice for structuring the nmethod-walking code >> correctly, and (b) help spotting bugs. > > Any hints on the kinds of bugs you may be seeing? My first overview of > the structure of yr changes looks fine, but i will do a second, more > careful, pass to see if i can spot any potential issues. > Please look at my last JPRT job. There were a lot of failures so I think I did something "obviously" wrong! Thanks very much! > later. > -- ramki > >> -- John > From Y.S.Ramakrishna at Sun.COM Tue Sep 8 16:06:41 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Tue, 08 Sep 2009 16:06:41 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4AA6D55D.4060901@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> <4AA6AE5D.206@Sun.COM> <4AA6D55D.4060901@Sun.COM> Message-ID: <4AA6E381.80503@Sun.COM> Sorry about doing the review in bits and pieces ... I underdstand now that some of my comments below may have been misplaced, given what i see on reading further into the webrev. See inline below... On 09/08/09 15:06, Y.S.Ramakrishna at Sun.COM wrote: > I've started looking at the entire webrev (the > second of the two links you provided below). > > I am not done yet, but had two small comments: > > (1) the "DetectScavengeRoot" closure appears to check for the > presence of any non-perm oop, whereas your interest is really > in something that is in a space subject to a partial collection > (i.e. a scavenge in our current collectors). So your current > check is too loose and will often identify nmethods to have > "scavengable" oops when in fact they do not (their references > having moved into the old gen which is only collected during > a full collection). I think you need to change the check:- > > 1651 virtual void do_oop(oop* p) { > 1652 if ((*p) != NULL && !(*p)->is_perm()) { > ^^^^^^^^^^^^^^^^ > !(*p)->is_is_young()) or equivalent > > 1653 NOT_PRODUCT(maybe_print(p)); > 1654 _detected_scavenge_root = true; > 1655 } > 1656 } So I came across this hunk:- > --- old/src/share/vm/gc_interface/collectedHeap.hpp 2009-09-08 01:01:02.000000000 -0700 > +++ new/src/share/vm/gc_interface/collectedHeap.hpp 2009-09-08 01:01:02.000000000 -0700 > @@ -256,6 +256,14 @@ > return p == NULL || is_in_permanent(p); > } > > + // An object is scavengable if its location may move during a scavenge. > + // (A scavenge is a GC which is not a full GC.) > + // Currently, this just means it is not perm (and not null). > + // This could change if we rethink what's in perm-gen. > + bool is_scavengable(const void *p) const { > + return !is_in_permanent_or_null(p); > + } > + where you clearly seem to have considered and postponed the more refined version of is_scavengable(), and in so doing, and after having seen the following hunk:- --- old/src/share/vm/memory/sharedHeap.cpp 2009-09-08 01:01:08.000000000 -0700 +++ new/src/share/vm/memory/sharedHeap.cpp 2009-09-08 01:01:08.000000000 -0700 ... @@ -157,10 +166,17 @@ if (!_process_strong_tasks->is_task_claimed(SH_PS_CodeCache_oops_do)) { if (so & SO_CodeCache) { + assert(collecting_perm_gen, "scanning all of code cache"); CodeCache::oops_do(roots); + } else if (so & (SO_SystemClasses|SO_AllClasses)) { + if (!collecting_perm_gen) { + // if we are collecting from class statics, but we are not going + // to visit all of the CodeCache, collect from the non-perm roots if any: + CodeCache::scavenge_root_nmethods_oops_do(roots); + } } // Verify if the code cache contents are in the perm gen - NOT_PRODUCT(CodeCache::oops_do(&assert_is_perm_closure)); + NOT_PRODUCT(CodeCache::asserted_non_scavengable_oops_do(&assert_is_perm_closure)); } I see that the following comment is misplaced:- > > (2) Could the removal of nmethods from the scavengable list following > flush get potentially expensive as you walk down the list to find the > appropriate nmethod (could the list get long, at least with > large young gens and with certain kinds of dynamic language > applications?). > Would it be worthwhile to make this scavengable list doubly linked > so as to allow constant time deletion? > Depends on how frequently nmethod flushing occurs in the new > world of scavengable oops in nmethods, i suppose... > > Next I'll go and check that the refs from the scavengable > list of nmethods act (in general, unless activations are present), > as weak roots, not strong roots (otherwise they would constitute a > temporary "leak" until the references got promoted to the old generation, > modulo my remark (1) above), but wanted to get these comments to > you first. ... because your intention, in fact, appears to be to treat these scavengable list of nmethods as strong roots (even if they do not have activations on thread stacks) and to wait for a full GC to reclaim or flush them. Could there be situations where these nmethods might hold the sole references to an otherwise unreachable oop? Might that cause a visible heap bloat until such time as a full gc will be called which will reclaim them? Somewhat relatedly, you weakened the following assertion in nmethod.cpp:- @@ -1350,7 +1372,10 @@ return false; } } - assert(unloading_occurred, "Inconsistency in unloading"); + // If ScavengeRootsInCode is true, an nmethod might be unloaded + // simply because one of its constant oops has gone dead. + // No actual classes need to be unloaded in order for this to occur. + assert(unloading_occurred || ScavengeRootsInCode, "Inconsistency in unloading"); make_unloaded(is_alive, obj); return true; } Was this necessitated because of the above possibility? (By the way, please make sure to merge yr changes with my recent push of some related changes for 4957990.) rest looks good (although as you hinted, a suitable structuring of the active nmethod "do_once" infrastructure so as to call the related prologue/epilogue in a more structured fashion might be worth thinking about). I'll go look at yr JPRT job later today and see if i have any ideas about the problems you are encountering. over and out. -- ramki From John.Rose at Sun.COM Tue Sep 8 22:49:03 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 22:49:03 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4AA6D55D.4060901@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> <4AA6AE5D.206@Sun.COM> <4AA6D55D.4060901@Sun.COM> Message-ID: On Sep 8, 2009, at 3:06 PM, Y.S.Ramakrishna at Sun.COM wrote: > I've started looking at the entire webrev (the > second of the two links you provided below). > > I am not done yet, but had two small comments: > > (1) the "DetectScavengeRoot" closure appears to check for the > presence of any non-perm oop, whereas your interest is really > in something that is in a space subject to a partial collection > (i.e. a scavenge in our current collectors). So your current > check is too loose and will often identify nmethods to have > "scavengable" oops when in fact they do not (their references > having moved into the old gen which is only collected during > a full collection). Good catch; thanks. That should have been in my introduction of is_scavengable. In those last two cases, I changed x->is_perm() => !x->is_scavengable(). > (2) Could the removal of nmethods from the scavengable list following > flush get potentially expensive as you walk down the list to find > the > appropriate nmethod (could the list get long, at least with > large young gens and with certain kinds of dynamic language > applications?). > Would it be worthwhile to make this scavengable list doubly linked > so as to allow constant time deletion? > Depends on how frequently nmethod flushing occurs in the new > world of scavengable oops in nmethods, i suppose... Nmethods are never removed one at a time. Instead, in each gc_epilogue, the list is traversed by prune_scavenge_root_nmethods. I suppose this could become expensive if there are many short GCs and the list is very long. (OTOH, that list must be traversed on every GC anyway, since it is part of the weak root set.) If this turns out to be a problem, we could do as you suggest, and have the sweeper perform the pruning logic incrementally. > Next I'll go and check that the refs from the scavengable > list of nmethods act (in general, unless activations are present), > as weak roots, not strong roots (otherwise they would constitute a > temporary "leak" until the references got promoted to the old > generation, > modulo my remark (1) above), but wanted to get these comments to > you first. Yes, thanks; that's an important thing to verify. Here's a complication to that assertion: Any nmethods (on the scavenge list or not!) which are being used by active stack frames function as strong roots. So those nmethods which are in *both* categories need a little extra thought. For this reason, among others, I'm now experimenting with having *all* OopClosures perform the nmethod mark check, so that between any pair of oops_do_marking_prologue/epilogue brackets, an nmethod will be processed at most once. -- John From John.Rose at Sun.COM Tue Sep 8 23:01:28 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 08 Sep 2009 23:01:28 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4AA6E381.80503@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> <4AA6AE5D.206@Sun.COM> <4AA6D55D.4060901@Sun.COM> <4AA6E381.80503@Sun.COM> Message-ID: <32F7C9CF-7B0A-438B-830C-E4FCC3997339@Sun.COM> On Sep 8, 2009, at 4:06 PM, Y.S.Ramakrishna at Sun.COM wrote: > Sorry about doing the review in bits and pieces ... I underdstand > now that some of my comments below may have been misplaced, > given what i see on reading further into the webrev. It's not a problem; the early feedback is helpful, and I hope in turn you don't mind that the target is moving as I discover more bugs. (Ideally, I'd like to push a change that will pass JPRT with the feature turned on to the maximum level... That might not be possible, in which case I'd like at least to pass current JRuby regression tests with the feature turned on to the "medium" level.) > ...and after having seen the following hunk:- > > --- old/src/share/vm/memory/sharedHeap.cpp 2009-09-08 > 01:01:08.000000000 -0700 > +++ new/src/share/vm/memory/sharedHeap.cpp 2009-09-08 > 01:01:08.000000000 -0700 > ... > @@ -157,10 +166,17 @@ > > if (!_process_strong_tasks- > >is_task_claimed(SH_PS_CodeCache_oops_do)) { > if (so & SO_CodeCache) { > + assert(collecting_perm_gen, "scanning all of code cache"); > CodeCache::oops_do(roots); > + } else if (so & (SO_SystemClasses|SO_AllClasses)) { > + if (!collecting_perm_gen) { > + // if we are collecting from class statics, but we are not > going > + // to visit all of the CodeCache, collect from the non- > perm roots if any: > + CodeCache::scavenge_root_nmethods_oops_do(roots); > + } > } > // Verify if the code cache contents are in the perm gen > - NOT_PRODUCT(CodeCache::oops_do(&assert_is_perm_closure)); > + > NOT_PRODUCT > (CodeCache > ::asserted_non_scavengable_oops_do(&assert_is_perm_closure)); > } > > I see that the following comment is misplaced:- > >> >> Would it be worthwhile to make this scavengable list doubly linked >> so as to allow constant time deletion? > > ... because your intention, in fact, appears to be to treat these > scavengable list of nmethods as strong roots (even if they do not > have activations on thread stacks) and to wait for a full GC to > reclaim or flush them. Could there be situations where these nmethods > might hold the sole references to an otherwise unreachable oop? > Might that cause a visible heap bloat until such time as a full gc > will be called which will reclaim them? Actually, I think you've pointed out a design bug: I want to treat those guys as weak roots (comparable to perm-gen references in the inactive but live nmethods within the code cache). > Somewhat relatedly, you weakened the following assertion in > nmethod.cpp:- > > @@ -1350,7 +1372,10 @@ > return false; > } > } > - assert(unloading_occurred, "Inconsistency in unloading"); > + // If ScavengeRootsInCode is true, an nmethod might be unloaded > + // simply because one of its constant oops has gone dead. > + // No actual classes need to be unloaded in order for this to > occur. > + assert(unloading_occurred || ScavengeRootsInCode, "Inconsistency > in unloading"); > make_unloaded(is_alive, obj); > return true; > } > > Was this necessitated because of the above possibility? No, I think it is simply an out-of-date assert that is incompatible with the logic of the new feature. (Or a cue that my design is wrong.) It says that the only way an nmethod's embedded weak oops can fail is if class unloading has just occurred. But this is not true if we allow new sources of non-perm oops into the code. If a random app- generated oop makes its way into the code, and the oops goes dead, the code needs to be thrown away. At least, that's my current thinking. A nice-to-have add on would be for the compiler to say "null this constant out when it goes dead" but we don't have a way to say that now. > (By the way, > please make sure to merge yr changes with my recent push of some > related changes for 4957990.) Will do. I see them in hotspot-gc. > rest looks good (although as you hinted, a suitable structuring of > the active nmethod "do_once" infrastructure so as to call the related > prologue/epilogue in a more structured fashion might be worth thinking > about). I'll go look at yr JPRT job later today and see if i have > any ideas about the problems you are encountering. I'm experimenting with abolishing the "do_nmethods" bit altogether, and having closures do the "do_nmethods" thing by default, and with test-and-set marking to ensure once-only processing. I suspect it will be easier to fix bugs from that starting point, than from the webrev you are looking at. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090908/4ec574c6/attachment.html From john.coomes at sun.com Wed Sep 9 01:42:26 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Wed, 09 Sep 2009 08:42:26 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6879076: disable jprt sync after builds are done Message-ID: <20090909084232.EC281E332@hg.openjdk.java.net> Changeset: b1f5ced5da21 Author: jcoomes Date: 2009-09-03 19:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b1f5ced5da21 6879076: disable jprt sync after builds are done Reviewed-by: kamg, dholmes ! make/jprt.properties From jeff.lloyd at algorithmics.com Thu Sep 10 13:06:54 2009 From: jeff.lloyd at algorithmics.com (jeff.lloyd at algorithmics.com) Date: Thu, 10 Sep 2009 16:06:54 -0400 Subject: Young generation configuration Message-ID: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> Hi, I'm new to this list and I have a few questions about tuning my young generation gc. I have chosen to use the CMS garbage collector because my application is a relatively large reporting server that has a web front end and therefore needs to have minimal pauses. I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB ram. The machine is dedicated to this JVM. My steady-state was calculated as follows: - A typical number of users logged in and viewed several reports - Stopped user actions and performed a manual full GC - Look at the amount of heap used and take that number as the steady-state memory requirement In this case my heap usage was ~10GB. In order to handle variance or spikes I sized my old generation at 15-20GB. I sized my young generation at 32-42GB and used survivor ratios of 1, 2, 3 and 6. My goal is to maximize throughput and minimize pauses. I'm willing to sacrifice ram to increase speed. I have attached several of my many gc logs. The file gc_48G.txt is just using CMS without any other tuning, and the results are much worse than what I have been able to accomplish with other settings. The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and gc_57G_15Gold_42Gyoung_1sr.txt. The problem is that some of the pauses are just too long. Is there a way to reduce the pause time any more than I have it now? Am I heading in the right direction? I ask because the default settings are so different than what I have been heading towards. The best reference I have found on what good gc logs look like come from brief examples presented at JavaOne this year by Tony Printezis and Charlie Hunt. But I don't seem to be able to get logs that resemble their tenuring patterns. I think I have a lot of medium-lived objects instead of nice short-lived ones. Are there any good practices for apps with objects like this? Thanks, Jeff -------------------------------------------------------------------------- This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory. -------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090910/55defd8d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: gc.zip Type: application/x-zip-compressed Size: 66850 bytes Desc: gc.zip Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090910/55defd8d/attachment-0001.bin -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at sun.com Thu Sep 10 22:33:11 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Fri, 11 Sep 2009 05:33:11 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6872136: CMS: confusing message may be printed when a collector is switched off implicitly Message-ID: <20090911053319.3615CEF1D@hg.openjdk.java.net> Changeset: 68ef3fdcdb76 Author: ysr Date: 2009-09-10 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/68ef3fdcdb76 6872136: CMS: confusing message may be printed when a collector is switched off implicitly Summary: Fix CDS/CMS option overrides related to iCMS option CMSIncrementalMode; explicate overrides to error stream. Reviewed-by: coleenp ! src/share/vm/runtime/arguments.cpp From tony.printezis at sun.com Fri Sep 11 08:22:17 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 11 Sep 2009 11:22:17 -0400 Subject: Young generation configuration In-Reply-To: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> Message-ID: <4AAA6B29.3030008@sun.com> Jeff, Hi. I had a very brief look at your logs. Yes, your app does seem to need to copy quite a lot (I don't think I've ever seen 1-2GB of data being copied in age 1!!!). From what I've seen from the space sizes, you're doing the right thing (i.e., you're consistent with what we talked about during the talk): you have quite large young gen and a reasonably sized old gen. But the sheer amount of surviving objects is what's getting you. How much larger can you make your young gen? I think in this case, the larger, the better. Maybe, you can also try MaxTenuringThreshold=1. This goes against our general advice, but this might decrease the amount of objects being copied during young GCs, at the expense of more frequent CMS cycles... Tony jeff.lloyd at algorithmics.com wrote: > > Hi, > > > > I?m new to this list and I have a few questions about tuning my young > generation gc. > > > > I have chosen to use the CMS garbage collector because my application > is a relatively large reporting server that has a web front end and > therefore needs to have minimal pauses. > > > > I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB ram. > > > > The machine is dedicated to this JVM. > > > > My steady-state was calculated as follows: > > - A typical number of users logged in and viewed several reports > > - Stopped user actions and performed a manual full GC > > - Look at the amount of heap used and take that number as the > steady-state memory requirement > > > > In this case my heap usage was ~10GB. In order to handle variance or > spikes I sized my old generation at 15-20GB. > > > > I sized my young generation at 32-42GB and used survivor ratios of 1, > 2, 3 and 6. > > > > My goal is to maximize throughput and minimize pauses. I?m willing to > sacrifice ram to increase speed. > > > > I have attached several of my many gc logs. The file gc_48G.txt is > just using CMS without any other tuning, and the results are much > worse than what I have been able to accomplish with other settings. > The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and > gc_57G_15Gold_42Gyoung_1sr.txt. > > > > The problem is that some of the pauses are just too long. > > > > Is there a way to reduce the pause time any more than I have it now? > > Am I heading in the right direction? I ask because the default > settings are so different than what I have been heading towards. > > > > The best reference I have found on what good gc logs look like come > from brief examples presented at JavaOne this year by Tony Printezis > and Charlie Hunt. But I don?t seem to be able to get logs that > resemble their tenuring patterns. > > > > I think I have a lot of medium-lived objects instead of nice > short-lived ones. > > > > Are there any good practices for apps with objects like this? > > > > Thanks, > > Jeff > > > > > ------------------------------------------------------------------------ > This email and any files transmitted with it are confidential and > proprietary to Algorithmics Incorporated and its affiliates > ("Algorithmics"). If received in error, use is prohibited. Please > destroy, and notify sender. Sender does not waive confidentiality or > privilege. Internet communications cannot be guaranteed to be timely, > secure, error or virus-free. Algorithmics does not accept liability > for any errors or omissions. Any commitment intended to bind > Algorithmics must be reduced to writing and signed by an authorized > signatory. > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Paul.Hohensee at Sun.COM Fri Sep 11 10:22:33 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 11 Sep 2009 13:22:33 -0400 Subject: Young generation configuration In-Reply-To: <4AAA6B29.3030008@sun.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> Message-ID: <4AAA8759.8010904@sun.com> Another alternative mentioned in Tony and Charlie's J1 slides is the parallel collector. If, as Tony says, you can make the young gen large enough to avoid promotion, and you really do have a steady state old gen, then which old gen collector you use wouldn't matter much to pause times, given that young gen pause times seem to be your immediate problem. It may be that you just need more hardware threads to collect such a big young gen too. You might vary the number of gc threads to see how that affects collection times. If there's significant differences, then you need more hardware threads, i.e., a bigger machine. You might also try using compressed pointers via -XX:+UseCompressedOops. That should cut down the total survivor size significantly, perhaps enough to that your current hardware threads can collect significantly faster. Heap size will be limited to < 32gb, but you're app will probably fit. A more efficient version of compressed pointers will be available in 6u18, btw. I notice that none of your logs shows more than age 7 stats even though the tenuring threshold is 15. It'd be nice to see if anything dies before then. Paul Tony Printezis wrote: > Jeff, > > Hi. I had a very brief look at your logs. Yes, your app does seem to > need to copy quite a lot (I don't think I've ever seen 1-2GB of data > being copied in age 1!!!). From what I've seen from the space sizes, > you're doing the right thing (i.e., you're consistent with what we > talked about during the talk): you have quite large young gen and a > reasonably sized old gen. But the sheer amount of surviving objects is > what's getting you. How much larger can you make your young gen? I think > in this case, the larger, the better. Maybe, you can also try > MaxTenuringThreshold=1. This goes against our general advice, but this > might decrease the amount of objects being copied during young GCs, at > the expense of more frequent CMS cycles... > > Tony > > jeff.lloyd at algorithmics.com wrote: > >> Hi, >> >> >> >> I?m new to this list and I have a few questions about tuning my young >> generation gc. >> >> >> >> I have chosen to use the CMS garbage collector because my application >> is a relatively large reporting server that has a web front end and >> therefore needs to have minimal pauses. >> >> >> >> I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB ram. >> >> >> >> The machine is dedicated to this JVM. >> >> >> >> My steady-state was calculated as follows: >> >> - A typical number of users logged in and viewed several reports >> >> - Stopped user actions and performed a manual full GC >> >> - Look at the amount of heap used and take that number as the >> steady-state memory requirement >> >> >> >> In this case my heap usage was ~10GB. In order to handle variance or >> spikes I sized my old generation at 15-20GB. >> >> >> >> I sized my young generation at 32-42GB and used survivor ratios of 1, >> 2, 3 and 6. >> >> >> >> My goal is to maximize throughput and minimize pauses. I?m willing to >> sacrifice ram to increase speed. >> >> >> >> I have attached several of my many gc logs. The file gc_48G.txt is >> just using CMS without any other tuning, and the results are much >> worse than what I have been able to accomplish with other settings. >> The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and >> gc_57G_15Gold_42Gyoung_1sr.txt. >> >> >> >> The problem is that some of the pauses are just too long. >> >> >> >> Is there a way to reduce the pause time any more than I have it now? >> >> Am I heading in the right direction? I ask because the default >> settings are so different than what I have been heading towards. >> >> >> >> The best reference I have found on what good gc logs look like come >> from brief examples presented at JavaOne this year by Tony Printezis >> and Charlie Hunt. But I don?t seem to be able to get logs that >> resemble their tenuring patterns. >> >> >> >> I think I have a lot of medium-lived objects instead of nice >> short-lived ones. >> >> >> >> Are there any good practices for apps with objects like this? >> >> >> >> Thanks, >> >> Jeff >> >> >> >> >> ------------------------------------------------------------------------ >> This email and any files transmitted with it are confidential and >> proprietary to Algorithmics Incorporated and its affiliates >> ("Algorithmics"). If received in error, use is prohibited. Please >> destroy, and notify sender. Sender does not waive confidentiality or >> privilege. Internet communications cannot be guaranteed to be timely, >> secure, error or virus-free. Algorithmics does not accept liability >> for any errors or omissions. Any commitment intended to bind >> Algorithmics must be reduced to writing and signed by an authorized >> signatory. >> ------------------------------------------------------------------------ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Y.S.Ramakrishna at Sun.COM Fri Sep 11 11:13:54 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Fri, 11 Sep 2009 11:13:54 -0700 Subject: Young generation configuration In-Reply-To: <4AAA8759.8010904@sun.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <4AAA8759.8010904@sun.com> Message-ID: <4AAA9362.3080009@Sun.COM> Just some very general remarks ... >> jeff.lloyd at algorithmics.com wrote: ... >>> My goal is to maximize throughput and minimize pauses. I?m willing to >>> sacrifice ram to increase speed. Ah, but you may not be able to achieve a joint optimum there; on the contrary, maximal throughput is often achieved at maximal pause times. Lowering pause times to within budget currently often involves giving up some throughput. You need to define the maximum pause time you can stand and the minimum throughput you can tolerate, and solve that optimization problem. ... >>> The problem is that some of the pauses are just too long. Hmm, good, we are getting closer :-) How long is "too long"? ... >>> Is there a way to reduce the pause time any more than I have it now? yes, but you will likely give up on throughput. >>> >>> Am I heading in the right direction? I ask because the default >>> settings are so different than what I have been heading towards. Depending on your boundary conditions (constraints on your objective metrics, and if you can define a suitable utility or objective function) there may be multiple optimal configurations, or none at all, which will meet your constraints. >>> I think I have a lot of medium-lived objects instead of nice >>> short-lived ones. You also have some short-lived ones (may be about 80%?), but yes you do have quite some (~15%?) of medium-lived ones. The total volume of such medium-lived objects is proportional to the transactional rate that your server is subject to, and also proportional to the longevity of those transactions (where i am using transactions loosely to mean how long it takes for the records associated with those transactions to flush their state). You mention that your application is a "reporting server". What is your estimate of the (expected/measured) lifetime of such a "reporting transaction"? Does it match the kinds of object lifetimes you are seeing here? -- ramki _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at sun.com Fri Sep 11 13:54:50 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 11 Sep 2009 16:54:50 -0400 Subject: Young generation configuration In-Reply-To: <0FCC438D62A5E643AA3F57D3417B220D0A813803@TORMAIL.algorithmics.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <0FCC438D62A5E643AA3F57D3417B220D0A813803@TORMAIL.algorithmics.com> Message-ID: <4AAAB91A.9020302@sun.com> jeff.lloyd at algorithmics.com wrote: > Hi Tony, > > We do have a lot of data that we create/copy within the application. We > hold big trees/graphs of data representing large portfolio structures in > memory per user. Slicing and dicing the data creates similar strains. > > I'll try to increase the YG and play more with MTT to see if I can speed > things up. The problem is that we have an interactive web interface so > the pauses need to be relatively quick or the UI responsiveness suffers. > > If I set MTT to 1, then I am guessing I may need to boost my OG size > because it will fill up faster. Would it make sense to increase the OG > size and reduce the initiating occupancy fraction? > Definitely. Someone was paying attention during the talk. :-) But, concentrate first on whether the young GC times are good enough. Tony > -----Original Message----- > From: Antonios.Printezis at sun.com [mailto:Antonios.Printezis at sun.com] On > Behalf Of Tony Printezis > Sent: Friday, September 11, 2009 11:22 AM > To: Jeff Lloyd > Cc: hotspot-gc-use at openjdk.java.net > Subject: Re: Young generation configuration > > Jeff, > > Hi. I had a very brief look at your logs. Yes, your app does seem to > need to copy quite a lot (I don't think I've ever seen 1-2GB of data > being copied in age 1!!!). From what I've seen from the space sizes, > you're doing the right thing (i.e., you're consistent with what we > talked about during the talk): you have quite large young gen and a > reasonably sized old gen. But the sheer amount of surviving objects is > what's getting you. How much larger can you make your young gen? I think > > in this case, the larger, the better. Maybe, you can also try > MaxTenuringThreshold=1. This goes against our general advice, but this > might decrease the amount of objects being copied during young GCs, at > the expense of more frequent CMS cycles... > > Tony > > jeff.lloyd at algorithmics.com wrote: > >> Hi, >> >> >> >> I'm new to this list and I have a few questions about tuning my young >> generation gc. >> >> >> >> I have chosen to use the CMS garbage collector because my application >> is a relatively large reporting server that has a web front end and >> therefore needs to have minimal pauses. >> >> >> >> I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB >> > ram. > >> >> >> The machine is dedicated to this JVM. >> >> >> >> My steady-state was calculated as follows: >> >> - A typical number of users logged in and viewed several >> > reports > >> - Stopped user actions and performed a manual full GC >> >> - Look at the amount of heap used and take that number as the >> > > >> steady-state memory requirement >> >> >> >> In this case my heap usage was ~10GB. In order to handle variance or >> spikes I sized my old generation at 15-20GB. >> >> >> >> I sized my young generation at 32-42GB and used survivor ratios of 1, >> 2, 3 and 6. >> >> >> >> My goal is to maximize throughput and minimize pauses. I'm willing to >> > > >> sacrifice ram to increase speed. >> >> >> >> I have attached several of my many gc logs. The file gc_48G.txt is >> just using CMS without any other tuning, and the results are much >> worse than what I have been able to accomplish with other settings. >> The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and >> gc_57G_15Gold_42Gyoung_1sr.txt. >> >> >> >> The problem is that some of the pauses are just too long. >> >> >> >> Is there a way to reduce the pause time any more than I have it now? >> >> Am I heading in the right direction? I ask because the default >> settings are so different than what I have been heading towards. >> >> >> >> The best reference I have found on what good gc logs look like come >> from brief examples presented at JavaOne this year by Tony Printezis >> and Charlie Hunt. But I don't seem to be able to get logs that >> resemble their tenuring patterns. >> >> >> >> I think I have a lot of medium-lived objects instead of nice >> short-lived ones. >> >> >> >> Are there any good practices for apps with objects like this? >> >> >> >> Thanks, >> >> Jeff >> >> >> >> >> >> > ------------------------------------------------------------------------ > >> This email and any files transmitted with it are confidential and >> proprietary to Algorithmics Incorporated and its affiliates >> ("Algorithmics"). If received in error, use is prohibited. Please >> destroy, and notify sender. Sender does not waive confidentiality or >> privilege. Internet communications cannot be guaranteed to be timely, >> secure, error or virus-free. Algorithmics does not accept liability >> for any errors or omissions. Any commitment intended to bind >> Algorithmics must be reduced to writing and signed by an authorized >> signatory. >> >> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > > -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jeff.lloyd at algorithmics.com Fri Sep 11 14:06:01 2009 From: jeff.lloyd at algorithmics.com (jeff.lloyd at algorithmics.com) Date: Fri, 11 Sep 2009 17:06:01 -0400 Subject: Young generation configuration In-Reply-To: <4AAA9362.3080009@Sun.COM> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <4AAA8759.8010904@sun.com> <4AAA9362.3080009@Sun.COM> Message-ID: <0FCC438D62A5E643AA3F57D3417B220D0A813842@TORMAIL.algorithmics.com> Hi Ramki, I did not know that lower pause times and higher throughput were generally incompatible. Good to know - it makes sense too. I'm trying to find out how long "too long" is. Bankers can be fickle. :-) Honestly, I think "too long" constitutes a noticeable pause in GUI interactions. How did you measure the proportion of short-lived and medium-lived objects? We typically expect a "session" be live for most of the day, and multiple reports of seconds or minutes in duration executed within that session. So yes, I am seeing my "steady state" continue for a long time, with blips of activity throughout the day. We cache a lot of results, which can lead to a general upward trend, but it doesn't seem to be our current source of object volume. Thanks for your help, Jeff -----Original Message----- From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM] Sent: Friday, September 11, 2009 2:14 PM To: Jeff Lloyd Cc: hotspot-gc-use at openjdk.java.net Subject: Re: Young generation configuration Just some very general remarks ... >> jeff.lloyd at algorithmics.com wrote: ... >>> My goal is to maximize throughput and minimize pauses. I'm willing to >>> sacrifice ram to increase speed. Ah, but you may not be able to achieve a joint optimum there; on the contrary, maximal throughput is often achieved at maximal pause times. Lowering pause times to within budget currently often involves giving up some throughput. You need to define the maximum pause time you can stand and the minimum throughput you can tolerate, and solve that optimization problem. ... >>> The problem is that some of the pauses are just too long. Hmm, good, we are getting closer :-) How long is "too long"? ... >>> Is there a way to reduce the pause time any more than I have it now? yes, but you will likely give up on throughput. >>> >>> Am I heading in the right direction? I ask because the default >>> settings are so different than what I have been heading towards. Depending on your boundary conditions (constraints on your objective metrics, and if you can define a suitable utility or objective function) there may be multiple optimal configurations, or none at all, which will meet your constraints. >>> I think I have a lot of medium-lived objects instead of nice >>> short-lived ones. You also have some short-lived ones (may be about 80%?), but yes you do have quite some (~15%?) of medium-lived ones. The total volume of such medium-lived objects is proportional to the transactional rate that your server is subject to, and also proportional to the longevity of those transactions (where i am using transactions loosely to mean how long it takes for the records associated with those transactions to flush their state). You mention that your application is a "reporting server". What is your estimate of the (expected/measured) lifetime of such a "reporting transaction"? Does it match the kinds of object lifetimes you are seeing here? -- ramki -------------------------------------------------------------------------- This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory. -------------------------------------------------------------------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Paul.Hohensee at Sun.COM Fri Sep 11 14:13:46 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 11 Sep 2009 17:13:46 -0400 Subject: Young generation configuration In-Reply-To: <0FCC438D62A5E643AA3F57D3417B220D0A813819@TORMAIL.algorithmics.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <4AAA8759.8010904@sun.com> <0FCC438D62A5E643AA3F57D3417B220D0A813819@TORMAIL.algorithmics.com> Message-ID: <4AAABD8A.7000900@sun.com> You can try out compressed pointers in 6u14. It just won't be quite as fast as the version that's going into 6u18. 6u14 with compressed pointers will still be quite a bit faster than without. One of the gc guys may correct me, but UseAdaptiveGCBoundary allows the vm to ergonomically move the boundary between old and young generations, effectively resizing them. I don't know if it's bit-rotted, and I seem to remember that there wasn't much benefit. But maybe we just didn't have a good use case. What I meant by the last paragraph was that with the tenuring threshold set at 15 (which is what the log says), and with only 7 young gcs in the log, we can't see at what age (or if) between 8 and 15 the survivor size goes down to something reasonable. If it doesn't, it might be worth it to us to revisit increasing the age limit for 64-bit. Paul jeff.lloyd at algorithmics.com wrote: > Thanks for your response Paul. > > I'll take another look at the parallel collector. > > That's a good point about the -XX:+UseCompressedOops. We started off > with heaps bigger than 32G so I had left that option out. I'll put it > back in and definitely try out 6u18 when it's available. > > What about the option -XX:+UseAdaptiveGCBoundary? I don't see it > referenced very often. Would it be helpful in a case like mine? > > I'm not sure I understand your last paragraph. What is the period of > time that you would be interested in seeing? > > Jeff > > -----Original Message----- > From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] > Sent: Friday, September 11, 2009 1:23 PM > To: Tony Printezis > Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net > Subject: Re: Young generation configuration > > Another alternative mentioned in Tony and Charlie's J1 slides is the > parallel > collector. If, as Tony says, you can make the young gen large enough to > > avoid > promotion, and you really do have a steady state old gen, then which old > gen > collector you use wouldn't matter much to pause times, given that young > gen pause times seem to be your immediate problem. > > It may be that you just need more hardware threads to collect such a big > > young > gen too. You might vary the number of gc threads to see how that > affects > collection times. If there's significant differences, then you need > more > hardware threads, i.e., a bigger machine. > > You might also try using compressed pointers via -XX:+UseCompressedOops. > That should cut down the total survivor size significantly, perhaps > enough > to that your current hardware threads can collect significantly faster. > > Heap size > will be limited to < 32gb, but you're app will probably fit. A more > efficient > version of compressed pointers will be available in 6u18, btw. > > I notice that none of your logs shows more than age 7 stats even though > the > tenuring threshold is 15. It'd be nice to see if anything dies before > then. > > Paul > > Tony Printezis wrote: > >> Jeff, >> >> Hi. I had a very brief look at your logs. Yes, your app does seem to >> need to copy quite a lot (I don't think I've ever seen 1-2GB of data >> being copied in age 1!!!). From what I've seen from the space sizes, >> you're doing the right thing (i.e., you're consistent with what we >> talked about during the talk): you have quite large young gen and a >> reasonably sized old gen. But the sheer amount of surviving objects is >> > > >> what's getting you. How much larger can you make your young gen? I >> > think > >> in this case, the larger, the better. Maybe, you can also try >> MaxTenuringThreshold=1. This goes against our general advice, but this >> > > >> might decrease the amount of objects being copied during young GCs, at >> > > >> the expense of more frequent CMS cycles... >> >> Tony >> >> jeff.lloyd at algorithmics.com wrote: >> >> >>> Hi, >>> >>> >>> >>> I'm new to this list and I have a few questions about tuning my young >>> > > >>> generation gc. >>> >>> >>> >>> I have chosen to use the CMS garbage collector because my application >>> > > >>> is a relatively large reporting server that has a web front end and >>> therefore needs to have minimal pauses. >>> >>> >>> >>> I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB >>> > ram. > >>> >>> >>> The machine is dedicated to this JVM. >>> >>> >>> >>> My steady-state was calculated as follows: >>> >>> - A typical number of users logged in and viewed several >>> > reports > >>> - Stopped user actions and performed a manual full GC >>> >>> - Look at the amount of heap used and take that number as >>> > the > >>> steady-state memory requirement >>> >>> >>> >>> In this case my heap usage was ~10GB. In order to handle variance or >>> > > >>> spikes I sized my old generation at 15-20GB. >>> >>> >>> >>> I sized my young generation at 32-42GB and used survivor ratios of 1, >>> > > >>> 2, 3 and 6. >>> >>> >>> >>> My goal is to maximize throughput and minimize pauses. I'm willing >>> > to > >>> sacrifice ram to increase speed. >>> >>> >>> >>> I have attached several of my many gc logs. The file gc_48G.txt is >>> just using CMS without any other tuning, and the results are much >>> worse than what I have been able to accomplish with other settings. >>> The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and >>> gc_57G_15Gold_42Gyoung_1sr.txt. >>> >>> >>> >>> The problem is that some of the pauses are just too long. >>> >>> >>> >>> Is there a way to reduce the pause time any more than I have it now? >>> >>> Am I heading in the right direction? I ask because the default >>> settings are so different than what I have been heading towards. >>> >>> >>> >>> The best reference I have found on what good gc logs look like come >>> from brief examples presented at JavaOne this year by Tony Printezis >>> and Charlie Hunt. But I don't seem to be able to get logs that >>> resemble their tenuring patterns. >>> >>> >>> >>> I think I have a lot of medium-lived objects instead of nice >>> short-lived ones. >>> >>> >>> >>> Are there any good practices for apps with objects like this? >>> >>> >>> >>> Thanks, >>> >>> Jeff >>> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ > >>> This email and any files transmitted with it are confidential and >>> proprietary to Algorithmics Incorporated and its affiliates >>> ("Algorithmics"). If received in error, use is prohibited. Please >>> destroy, and notify sender. Sender does not waive confidentiality or >>> privilege. Internet communications cannot be guaranteed to be timely, >>> > > >>> secure, error or virus-free. Algorithmics does not accept liability >>> for any errors or omissions. Any commitment intended to bind >>> Algorithmics must be reduced to writing and signed by an authorized >>> signatory. >>> >>> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>> >>> >> >> > > > -------------------------------------------------------------------------- > This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory. > -------------------------------------------------------------------------- > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at sun.com Fri Sep 11 14:17:55 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 11 Sep 2009 17:17:55 -0400 Subject: Young generation configuration In-Reply-To: <4AAABD8A.7000900@sun.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <4AAA8759.8010904@sun.com> <0FCC438D62A5E643AA3F57D3417B220D0A813819@TORMAIL.algorithmics.com> <4AAABD8A.7000900@sun.com> Message-ID: <4AAABE83.90308@sun.com> Paul Hohensee wrote: > You can try out compressed pointers in 6u14. It just won't be quite as > fast as the version that's going into 6u18. 6u14 with compressed pointers > will still be quite a bit faster than without. > > One of the gc guys may correct me, but UseAdaptiveGCBoundary allows > the vm to ergonomically move the boundary between old and young generations, > effectively resizing them. I don't know if it's bit-rotted, and I seem > to remember > that there wasn't much benefit. But maybe we just didn't have a good > use case. > Also, it's ParallelGC-only, IIRC. > What I meant by the last paragraph was that with the tenuring threshold > set at > 15 (which is what the log says), and with only 7 young gcs in the log, > we can't > see at what age (or if) between 8 and 15 the survivor size goes down to > something > reasonable. If it doesn't, it might be worth it to us to revisit > increasing the age > limit for 64-bit. > Paul, the problem in Jeff's case is that even at age 1 he copies 1GB or so. So, maybe, setting a small MTT and having more CMS cycles might be the right option for him. Tony > jeff.lloyd at algorithmics.com wrote: > >> Thanks for your response Paul. >> >> I'll take another look at the parallel collector. >> >> That's a good point about the -XX:+UseCompressedOops. We started off >> with heaps bigger than 32G so I had left that option out. I'll put it >> back in and definitely try out 6u18 when it's available. >> >> What about the option -XX:+UseAdaptiveGCBoundary? I don't see it >> referenced very often. Would it be helpful in a case like mine? >> >> I'm not sure I understand your last paragraph. What is the period of >> time that you would be interested in seeing? >> >> Jeff >> >> -----Original Message----- >> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] >> Sent: Friday, September 11, 2009 1:23 PM >> To: Tony Printezis >> Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net >> Subject: Re: Young generation configuration >> >> Another alternative mentioned in Tony and Charlie's J1 slides is the >> parallel >> collector. If, as Tony says, you can make the young gen large enough to >> >> avoid >> promotion, and you really do have a steady state old gen, then which old >> gen >> collector you use wouldn't matter much to pause times, given that young >> gen pause times seem to be your immediate problem. >> >> It may be that you just need more hardware threads to collect such a big >> >> young >> gen too. You might vary the number of gc threads to see how that >> affects >> collection times. If there's significant differences, then you need >> more >> hardware threads, i.e., a bigger machine. >> >> You might also try using compressed pointers via -XX:+UseCompressedOops. >> That should cut down the total survivor size significantly, perhaps >> enough >> to that your current hardware threads can collect significantly faster. >> >> Heap size >> will be limited to < 32gb, but you're app will probably fit. A more >> efficient >> version of compressed pointers will be available in 6u18, btw. >> >> I notice that none of your logs shows more than age 7 stats even though >> the >> tenuring threshold is 15. It'd be nice to see if anything dies before >> then. >> >> Paul >> >> Tony Printezis wrote: >> >> >>> Jeff, >>> >>> Hi. I had a very brief look at your logs. Yes, your app does seem to >>> need to copy quite a lot (I don't think I've ever seen 1-2GB of data >>> being copied in age 1!!!). From what I've seen from the space sizes, >>> you're doing the right thing (i.e., you're consistent with what we >>> talked about during the talk): you have quite large young gen and a >>> reasonably sized old gen. But the sheer amount of surviving objects is >>> >>> >> >> >>> what's getting you. How much larger can you make your young gen? I >>> >>> >> think >> >> >>> in this case, the larger, the better. Maybe, you can also try >>> MaxTenuringThreshold=1. This goes against our general advice, but this >>> >>> >> >> >>> might decrease the amount of objects being copied during young GCs, at >>> >>> >> >> >>> the expense of more frequent CMS cycles... >>> >>> Tony >>> >>> jeff.lloyd at algorithmics.com wrote: >>> >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> I'm new to this list and I have a few questions about tuning my young >>>> >>>> >> >> >>>> generation gc. >>>> >>>> >>>> >>>> I have chosen to use the CMS garbage collector because my application >>>> >>>> >> >> >>>> is a relatively large reporting server that has a web front end and >>>> therefore needs to have minimal pauses. >>>> >>>> >>>> >>>> I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB >>>> >>>> >> ram. >> >> >>>> >>>> >>>> The machine is dedicated to this JVM. >>>> >>>> >>>> >>>> My steady-state was calculated as follows: >>>> >>>> - A typical number of users logged in and viewed several >>>> >>>> >> reports >> >> >>>> - Stopped user actions and performed a manual full GC >>>> >>>> - Look at the amount of heap used and take that number as >>>> >>>> >> the >> >> >>>> steady-state memory requirement >>>> >>>> >>>> >>>> In this case my heap usage was ~10GB. In order to handle variance or >>>> >>>> >> >> >>>> spikes I sized my old generation at 15-20GB. >>>> >>>> >>>> >>>> I sized my young generation at 32-42GB and used survivor ratios of 1, >>>> >>>> >> >> >>>> 2, 3 and 6. >>>> >>>> >>>> >>>> My goal is to maximize throughput and minimize pauses. I'm willing >>>> >>>> >> to >> >> >>>> sacrifice ram to increase speed. >>>> >>>> >>>> >>>> I have attached several of my many gc logs. The file gc_48G.txt is >>>> just using CMS without any other tuning, and the results are much >>>> worse than what I have been able to accomplish with other settings. >>>> The best results are in the files gc_52G_20Gold_32Gyoung_2sr.txt and >>>> gc_57G_15Gold_42Gyoung_1sr.txt. >>>> >>>> >>>> >>>> The problem is that some of the pauses are just too long. >>>> >>>> >>>> >>>> Is there a way to reduce the pause time any more than I have it now? >>>> >>>> Am I heading in the right direction? I ask because the default >>>> settings are so different than what I have been heading towards. >>>> >>>> >>>> >>>> The best reference I have found on what good gc logs look like come >>>> from brief examples presented at JavaOne this year by Tony Printezis >>>> and Charlie Hunt. But I don't seem to be able to get logs that >>>> resemble their tenuring patterns. >>>> >>>> >>>> >>>> I think I have a lot of medium-lived objects instead of nice >>>> short-lived ones. >>>> >>>> >>>> >>>> Are there any good practices for apps with objects like this? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jeff >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> ------------------------------------------------------------------------ >> >> >>>> This email and any files transmitted with it are confidential and >>>> proprietary to Algorithmics Incorporated and its affiliates >>>> ("Algorithmics"). If received in error, use is prohibited. Please >>>> destroy, and notify sender. Sender does not waive confidentiality or >>>> privilege. Internet communications cannot be guaranteed to be timely, >>>> >>>> >> >> >>>> secure, error or virus-free. Algorithmics does not accept liability >>>> for any errors or omissions. Any commitment intended to bind >>>> Algorithmics must be reduced to writing and signed by an authorized >>>> signatory. >>>> >>>> >>>> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------ >> >> >>>> _______________________________________________ >>>> hotspot-gc-use mailing list >>>> hotspot-gc-use at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>> >>>> >>>> >>> >>> >>> >> >> -------------------------------------------------------------------------- >> This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory. >> -------------------------------------------------------------------------- >> >> > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Y.S.Ramakrishna at Sun.COM Fri Sep 11 15:19:46 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Fri, 11 Sep 2009 15:19:46 -0700 Subject: Young generation configuration In-Reply-To: <0FCC438D62A5E643AA3F57D3417B220D0A813842@TORMAIL.algorithmics.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <4AAA8759.8010904@sun.com> <4AAA9362.3080009@Sun.COM> <0FCC438D62A5E643AA3F57D3417B220D0A813842@TORMAIL.algorithmics.com> Message-ID: <4AAACD02.4040109@Sun.COM> Hi Jeff -- On 09/11/09 14:06, jeff.lloyd at algorithmics.com wrote: > Hi Ramki, > > I did not know that lower pause times and higher throughput were > generally incompatible. Good to know - it makes sense too. > > I'm trying to find out how long "too long" is. Bankers can be fickle. > :-) Honestly, I think "too long" constitutes a noticeable pause in GUI > interactions. So, may be around one 200 ms pause per second or so at the most? (If you think that is not suitable, think up a suitable figure like that.) That would give us the requisite pause time budget and implicitly define a GC overhead budget of 200/1000 = 20% (which is actually quite high, but still lower than the overhead i saw in some of your logs from a quick browse, but as Tony pointed out that's because of the excessive copying you were doing of relatively long-lived data that you may be better off tenuring more quickly and letting the concurrent collector deal with it (modulo yr & Tony's earlier remarks re the slightly (see below) increased pressure -- probably unavoidable if you are to meet yr pause time goals -- on the concurrent collector). > > How did you measure the proportion of short-lived and medium-lived > objects? oh, i was playing somewhat fast and loose. I was taking the ratio of (age 1 survivors): (Eden size) to get a rough read on the short:(not short). I sampled a single GC from one of yr log files, but that would be the way to figure this out (while averaging over a sufficiently large set of samples). (Of course, "long" and "short", are relative, and age1 just tells you what survived that was allocated in the last GC epoch. If GC's happen frequently less data would die and more would qualify as "not short" by that kind of loose definition (so my "long" and "short" was relative to the given GC period). > > We typically expect a "session" be live for most of the day, and How much typical session data do you have? What is the rate at which sessions get created? Does this happen perhaps mostly at the start of the day? (In which case you would see lots of promotion activity at the start of the day, but not so much later in the day?) Or is the session creation rate uniform through the typical day? > multiple reports of seconds or minutes in duration executed within that > session. So yes, I am seeing my "steady state" continue for a long Let's say 1 minute. So during that 1 minute, how much data do you produce and of that how much needs to be saved into the session in the form of the "result" from that report? Looks like that result would constitute data that you want to tenure sooner rather than later. Depending on how long the intermediate results needed to generate the final result are needed (you mentioned large trees of intermediate objects i think in an earlier email), you may want to copy them in the survivor spaces, or -- if that data is so large as to cost excessive copying time -- just promote that too. Luckily, in typical cases, if data wants to be large, it also wants to live long. > time, with blips of activity throughout the day. We cache a lot of > results, which can lead to a general upward trend, but it doesn't seem > to be our current source of object volume. The cached data will tenure. Best to tenure it soon, if the proportion of cached data is large. (I am guessing that if you cache, you probably find it saves computation later -- so it also saves allocation later; thus I might naively expect that you will initially tenure lots of data as your caches fill, and later in steady state tenure less as well as perhaps allocate less.) If I look at one random tenuring distribution sample out of yr logs, I see:- - age 1: 2151744736 bytes, 2151744736 total - age 2: 897330448 bytes, 3049075184 total - age 3: 1274314280 bytes, 4323389464 total - age 4: 1351603024 bytes, 5674992488 total - age 5: 1529394376 bytes, 7204386864 total - age 6: 1219001160 bytes, 8423388024 total which is very flat -- indicating that anything that survives a scavenge appears to live on for quite a while (lots of assumptions about steady loads and so on). Experimenting with an MTT of 1 or 2 might be useful, cf yr previous emails with Tony et al. (Yes you will want to increase yr OG size, as you noted, but no it will not fill up much faster because the rate at which you promote will be nearly the same, because most data that survives a single scavenge here tends to live -- above -- for at least 6 scavenges after which it prmotes anyway; you are just promoting that same data a bit sooner without wasting effort in copying it back and forth. It is true that some small amount if intermediate data will promote but that's probably OK). You will then want to play with initiating occupancy fraction once you get an idea about the rate at which it's filling upo versus the rate at which CMS is able to collect versus the effect on scavenges of letting the CMS gen fill up more before collecting versus the effect of doing more frequent or less frequent CMS cycles (and its effect on mutator throughput and available CPU and memory bandwidth). Yes, as Paul noted, definitely +UseCompressedOops to relieve heap pressure (reduce GC overhead) and speed up mutators by improving cache efficiency. -- ramki _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Paul.Hohensee at Sun.COM Fri Sep 11 17:00:02 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 11 Sep 2009 20:00:02 -0400 Subject: Young generation configuration In-Reply-To: <4AAABE83.90308@sun.com> References: <0FCC438D62A5E643AA3F57D3417B220D0A7AE2ED@TORMAIL.algorithmics.com> <4AAA6B29.3030008@sun.com> <4AAA8759.8010904@sun.com> <0FCC438D62A5E643AA3F57D3417B220D0A813819@TORMAIL.algorithmics.com> <4AAABD8A.7000900@sun.com> <4AAABE83.90308@sun.com> Message-ID: <4AAAE482.7070200@sun.com> Could be, but that would lead to a lot of concurrent overhead, reducing his throughput. Such a balancing act. :) Paul Tony Printezis wrote: > > > Paul Hohensee wrote: >> You can try out compressed pointers in 6u14. It just won't be quite as >> fast as the version that's going into 6u18. 6u14 with compressed >> pointers >> will still be quite a bit faster than without. >> >> One of the gc guys may correct me, but UseAdaptiveGCBoundary allows >> the vm to ergonomically move the boundary between old and young >> generations, >> effectively resizing them. I don't know if it's bit-rotted, and I >> seem to remember >> that there wasn't much benefit. But maybe we just didn't have a good >> use case. >> > Also, it's ParallelGC-only, IIRC. >> What I meant by the last paragraph was that with the tenuring >> threshold set at >> 15 (which is what the log says), and with only 7 young gcs in the >> log, we can't >> see at what age (or if) between 8 and 15 the survivor size goes down >> to something >> reasonable. If it doesn't, it might be worth it to us to revisit >> increasing the age >> limit for 64-bit. >> > Paul, the problem in Jeff's case is that even at age 1 he copies 1GB > or so. So, maybe, setting a small MTT and having more CMS cycles might > be the right option for him. > > Tony >> jeff.lloyd at algorithmics.com wrote: >> >>> Thanks for your response Paul. >>> >>> I'll take another look at the parallel collector. >>> That's a good point about the -XX:+UseCompressedOops. We started off >>> with heaps bigger than 32G so I had left that option out. I'll put it >>> back in and definitely try out 6u18 when it's available. >>> >>> What about the option -XX:+UseAdaptiveGCBoundary? I don't see it >>> referenced very often. Would it be helpful in a case like mine? >>> >>> I'm not sure I understand your last paragraph. What is the period of >>> time that you would be interested in seeing? >>> >>> Jeff >>> >>> -----Original Message----- >>> From: Paul.Hohensee at Sun.COM [mailto:Paul.Hohensee at Sun.COM] Sent: >>> Friday, September 11, 2009 1:23 PM >>> To: Tony Printezis >>> Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net >>> Subject: Re: Young generation configuration >>> >>> Another alternative mentioned in Tony and Charlie's J1 slides is the >>> parallel >>> collector. If, as Tony says, you can make the young gen large >>> enough to >>> >>> avoid >>> promotion, and you really do have a steady state old gen, then which >>> old >>> gen >>> collector you use wouldn't matter much to pause times, given that young >>> gen pause times seem to be your immediate problem. >>> >>> It may be that you just need more hardware threads to collect such a >>> big >>> >>> young >>> gen too. You might vary the number of gc threads to see how that >>> affects >>> collection times. If there's significant differences, then you need >>> more >>> hardware threads, i.e., a bigger machine. >>> >>> You might also try using compressed pointers via >>> -XX:+UseCompressedOops. >>> That should cut down the total survivor size significantly, perhaps >>> enough >>> to that your current hardware threads can collect significantly faster. >>> >>> Heap size >>> will be limited to < 32gb, but you're app will probably fit. A more >>> efficient >>> version of compressed pointers will be available in 6u18, btw. >>> >>> I notice that none of your logs shows more than age 7 stats even though >>> the >>> tenuring threshold is 15. It'd be nice to see if anything dies before >>> then. >>> >>> Paul >>> >>> Tony Printezis wrote: >>> >>>> Jeff, >>>> >>>> Hi. I had a very brief look at your logs. Yes, your app does seem >>>> to need to copy quite a lot (I don't think I've ever seen 1-2GB of >>>> data being copied in age 1!!!). From what I've seen from the space >>>> sizes, you're doing the right thing (i.e., you're consistent with >>>> what we talked about during the talk): you have quite large young >>>> gen and a reasonably sized old gen. But the sheer amount of >>>> surviving objects is >>>> >>> >>>> what's getting you. How much larger can you make your young gen? I >>>> >>> think >>>> in this case, the larger, the better. Maybe, you can also try >>>> MaxTenuringThreshold=1. This goes against our general advice, but this >>>> >>> >>>> might decrease the amount of objects being copied during young GCs, at >>>> >>> >>>> the expense of more frequent CMS cycles... >>>> >>>> Tony >>>> >>>> jeff.lloyd at algorithmics.com wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I'm new to this list and I have a few questions about tuning my young >>>>> >>> >>>>> generation gc. >>>>> >>>>> >>>>> >>>>> I have chosen to use the CMS garbage collector because my application >>>>> >>> >>>>> is a relatively large reporting server that has a web front end >>>>> and therefore needs to have minimal pauses. >>>>> >>>>> >>>>> I am using java 1.6.0_16 64-bit on redhat 5.2 intel 8x3GHz and 64GB >>>>> >>> ram. >>> >>>>> >>>>> >>>>> The machine is dedicated to this JVM. >>>>> >>>>> >>>>> >>>>> My steady-state was calculated as follows: >>>>> >>>>> - A typical number of users logged in and viewed several >>>>> >>> reports >>> >>>>> - Stopped user actions and performed a manual full GC >>>>> >>>>> - Look at the amount of heap used and take that number as >>>>> >>> the >>>>> steady-state memory requirement >>>>> >>>>> >>>>> >>>>> In this case my heap usage was ~10GB. In order to handle variance or >>>>> >>> >>>>> spikes I sized my old generation at 15-20GB. >>>>> >>>>> >>>>> >>>>> I sized my young generation at 32-42GB and used survivor ratios of 1, >>>>> >>> >>>>> 2, 3 and 6. >>>>> >>>>> >>>>> >>>>> My goal is to maximize throughput and minimize pauses. I'm willing >>>>> >>> to >>>>> sacrifice ram to increase speed. >>>>> >>>>> >>>>> >>>>> I have attached several of my many gc logs. The file gc_48G.txt >>>>> is just using CMS without any other tuning, and the results are >>>>> much worse than what I have been able to accomplish with other >>>>> settings. The best results are in the files >>>>> gc_52G_20Gold_32Gyoung_2sr.txt and gc_57G_15Gold_42Gyoung_1sr.txt. >>>>> >>>>> >>>>> >>>>> The problem is that some of the pauses are just too long. >>>>> >>>>> >>>>> >>>>> Is there a way to reduce the pause time any more than I have it now? >>>>> >>>>> Am I heading in the right direction? I ask because the default >>>>> settings are so different than what I have been heading towards. >>>>> >>>>> >>>>> >>>>> The best reference I have found on what good gc logs look like >>>>> come from brief examples presented at JavaOne this year by Tony >>>>> Printezis and Charlie Hunt. But I don't seem to be able to get >>>>> logs that resemble their tenuring patterns. >>>>> >>>>> >>>>> >>>>> I think I have a lot of medium-lived objects instead of nice >>>>> short-lived ones. >>>>> >>>>> >>>>> >>>>> Are there any good practices for apps with objects like this? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jeff >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> ------------------------------------------------------------------------ >>> >>> >>>>> This email and any files transmitted with it are confidential and >>>>> proprietary to Algorithmics Incorporated and its affiliates >>>>> ("Algorithmics"). If received in error, use is prohibited. Please >>>>> destroy, and notify sender. Sender does not waive confidentiality >>>>> or privilege. Internet communications cannot be guaranteed to be >>>>> timely, >>>>> >>> >>>>> secure, error or virus-free. Algorithmics does not accept >>>>> liability for any errors or omissions. Any commitment intended to >>>>> bind Algorithmics must be reduced to writing and signed by an >>>>> authorized signatory. >>>>> >>>>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>>> >>>> >>> >>> -------------------------------------------------------------------------- >>> >>> This email and any files transmitted with it are confidential and >>> proprietary to Algorithmics Incorporated and its affiliates >>> ("Algorithmics"). If received in error, use is prohibited. Please >>> destroy, and notify sender. Sender does not waive confidentiality or >>> privilege. Internet communications cannot be guaranteed to be >>> timely, secure, error or virus-free. Algorithmics does not accept >>> liability for any errors or omissions. Any commitment intended to >>> bind Algorithmics must be reduced to writing and signed by an >>> authorized signatory. >>> -------------------------------------------------------------------------- >>> >>> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From John.Rose at Sun.COM Sat Sep 12 03:16:07 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 12 Sep 2009 03:16:07 -0700 Subject: for review (M): 6863023: need non-perm oops in code cache for JSR 292 In-Reply-To: <4AA6E381.80503@Sun.COM> References: <01A90166-7F50-4218-B38A-345C7CA7ABF7@sun.com> <7575205F-F595-4348-A57F-B226AADBEB50@sun.com> <458FA846-61F1-4DCC-A83B-C89B3F8D95B0@Sun.COM> <0DA85138-5F50-461C-8A4D-C0F77218E022@Sun.COM> <9F4EB16A-77A4-49C8-8E4E-CC79921B0847@Sun.COM> <490D444C-294F-46F9-AA59-B7CE77C08145@Sun.COM> <4AA6AE5D.206@Sun.COM> <4AA6D55D.4060901@Sun.COM> <4AA6E381.80503@Sun.COM> Message-ID: Here is an updated webrev. The operations of the GC relative to the code cache are much more explicit now: http://cr.openjdk.java.net/~jrose/6863023/webrev.06 This one (a) is about to pass JPRT, (b) does pass unit tests like GCBasher and GCOld in various stress modes, (c) does run various JRuby +invokedynamic benchmarks successfully. I've been routinely testing with all four GC modes. I think it's ready to go back, as soon as a GC person verifies that my GC-related refactorings are reasonable. The other parts of the code are already reviewed. -- John P.S. The two stress modes I've mostly used are are ScavengeRootsInCode=2 and ScavengeRootsInCode=2 with -Xcomp. These modes tend to create a lot of nmethods with non-perm oops embedded. The default I'm going to push is ScavengeRootsInCode=0. When invokedynamic is turned on by default, the flag will change to ScavengeRootsInCode=1, which means non-perm oops will be inserted into code for invokedynamic, but not for user-written Java code. From y.s.ramakrishna at sun.com Wed Sep 16 03:18:53 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Wed, 16 Sep 2009 10:18:53 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6861557: G1: assert(top() == bottom() || zfs == Allocated, "Region must be empty, or ...") Message-ID: <20090916101901.46665122B0@hg.openjdk.java.net> Changeset: eb058abd0562 Author: ysr Date: 2009-09-15 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/eb058abd0562 6861557: G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or ...") Summary: Druing heap shrinking, check for emptiness of a region before modifying its ZF status. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp From john.coomes at sun.com Thu Sep 17 21:38:53 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:38:53 +0000 Subject: hg: jdk7/hotspot-gc: 3 new changesets Message-ID: <20090918043854.1E62A12416@hg.openjdk.java.net> Changeset: 4079d923a501 Author: peterz Date: 2009-08-31 14:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/4079d923a501 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README-builds.html Changeset: 0d7e03b426df Author: yan Date: 2009-09-09 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/0d7e03b426df Merge Changeset: 4c4fe09fb670 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/4c4fe09fb670 Added tag jdk7-b72 for changeset 0d7e03b426df ! .hgtags From john.coomes at sun.com Thu Sep 17 21:39:21 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:39:21 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b72 for changeset c793a3120926 Message-ID: <20090918043923.69DD31241B@hg.openjdk.java.net> Changeset: 12991b453239 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/12991b453239 Added tag jdk7-b72 for changeset c793a3120926 ! .hgtags From john.coomes at sun.com Thu Sep 17 21:42:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:42:42 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b72 for changeset 37c805b6156f Message-ID: <20090918044245.7AA8A12420@hg.openjdk.java.net> Changeset: 93dfa6e0fe76 Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/93dfa6e0fe76 Added tag jdk7-b72 for changeset 37c805b6156f ! .hgtags From john.coomes at sun.com Thu Sep 17 21:43:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:43:14 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b72 for changeset 4c990aa99bc0 Message-ID: <20090918044316.BD9BE12425@hg.openjdk.java.net> Changeset: d79f0d601c2b Author: xdono Date: 2009-09-17 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/d79f0d601c2b Added tag jdk7-b72 for changeset 4c990aa99bc0 ! .hgtags From john.coomes at sun.com Thu Sep 17 21:44:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 04:44:54 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 52 new changesets Message-ID: <20090918045603.716641242A@hg.openjdk.java.net> Changeset: b115cf946852 Author: sherman Date: 2009-08-25 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b115cf946852 4963968: zlib should be upgraded to current version of zlib Summary: upgrade zlib to the latest ver 1.2.3 Reviewed-by: martin, alanb, ksrini ! make/com/sun/java/pack/Makefile ! make/common/Defs.gmk ! make/java/jli/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/reorder-i586 ! make/java/zip/reorder-sparc ! make/java/zip/reorder-sparcv9 ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.3/ChangeLog + src/share/native/java/util/zip/zlib-1.2.3/README + src/share/native/java/util/zip/zlib-1.2.3/compress.c + src/share/native/java/util/zip/zlib-1.2.3/crc32.h + src/share/native/java/util/zip/zlib-1.2.3/deflate.c + src/share/native/java/util/zip/zlib-1.2.3/deflate.h + src/share/native/java/util/zip/zlib-1.2.3/gzio.c + src/share/native/java/util/zip/zlib-1.2.3/infback.c + src/share/native/java/util/zip/zlib-1.2.3/inffast.c + src/share/native/java/util/zip/zlib-1.2.3/inffast.h + src/share/native/java/util/zip/zlib-1.2.3/inffixed.h + src/share/native/java/util/zip/zlib-1.2.3/inflate.c + src/share/native/java/util/zip/zlib-1.2.3/inflate.h + src/share/native/java/util/zip/zlib-1.2.3/inftrees.c + src/share/native/java/util/zip/zlib-1.2.3/inftrees.h + src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff + src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff + src/share/native/java/util/zip/zlib-1.2.3/trees.c + src/share/native/java/util/zip/zlib-1.2.3/trees.h + src/share/native/java/util/zip/zlib-1.2.3/uncompr.c + src/share/native/java/util/zip/zlib-1.2.3/zadler32.c + src/share/native/java/util/zip/zlib-1.2.3/zconf.h + src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.3/zlib.h + src/share/native/java/util/zip/zlib-1.2.3/zutil.c + src/share/native/java/util/zip/zlib-1.2.3/zutil.h Changeset: 196c7bb551e7 Author: darcy Date: 2009-08-25 18:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/196c7bb551e7 6875861: javadoc build warning on java.util.Properites from unconventional @see ordering Reviewed-by: martin ! src/share/classes/java/util/Properties.java Changeset: 2607e571a6d5 Author: weijun Date: 2009-08-26 12:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2607e571a6d5 6868864: Kerberos tests fail under windows/cygwin Reviewed-by: wetmore ! test/sun/security/krb5/auto/basic.sh Changeset: 69396f593772 Author: dl Date: 2009-08-25 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/69396f593772 6871697: LinkedBlockingQueue Iterator/remove/poll race Summary: More checks for node.next == node Reviewed-by: martin, dholmes, chegar ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: aeaf7b138d90 Author: dl Date: 2009-08-25 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/aeaf7b138d90 6868712: Improve concurrent queue tests Summary: Fix all known flaky tests, plus minor maintenance Reviewed-by: martin, chegar ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/IteratorAtEnd.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/PriorityQueue/RemoveContains.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java + test/java/util/concurrent/BlockingQueue/LastElement.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java ! test/java/util/concurrent/BlockingQueue/PollMemoryLeak.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java + test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 25371bf31658 Author: darcy Date: 2009-08-27 11:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/25371bf31658 6876628: @throw instead of @throws in two ParagraphView classes Reviewed-by: peterz ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/html/ParagraphView.java Changeset: 5342b0cdbf95 Author: xlu Date: 2009-08-27 18:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5342b0cdbf95 6876282: BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces incorrect result Reviewed-by: darcy ! src/share/classes/java/math/BigDecimal.java ! test/java/math/BigDecimal/DivideTests.java Changeset: 4a5f2147f953 Author: darcy Date: 2009-08-28 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4a5f2147f953 6877122: Many javadoc warnings from java.awt.Window, other awt classes Reviewed-by: anthony ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/dnd/DragSourceContext.java Changeset: e0f79982edd2 Author: darcy Date: 2009-08-28 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e0f79982edd2 6261502: (reflect) Add the functionality to screen out the "inappropriate" modifier bits Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java Changeset: 225aa5ee10da Author: tbell Date: 2009-08-28 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/225aa5ee10da Merge ! src/share/classes/javax/swing/text/ParagraphView.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: db5d6b4cbc11 Author: martin Date: 2009-08-31 15:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/db5d6b4cbc11 6860431: Character.isSurrogate(char ch) Summary: Add new method Character.isSurrogate(char ch) Reviewed-by: sherman, darcy, okutsu ! src/share/classes/java/lang/Character.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/nio/cs/ISO_8859_1.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/Surrogate.java ! src/share/classes/sun/nio/cs/US_ASCII.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeDecoder.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/DoubleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java Changeset: ed0863629d28 Author: tbell Date: 2009-09-03 18:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ed0863629d28 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: ee5300e1835a Author: weijun Date: 2009-09-04 14:58 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ee5300e1835a 6876328: different names for the same digest algorithms breaks jarsigner Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/nameclash.sh Changeset: 98ad1322051e Author: weijun Date: 2009-09-04 14:59 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/98ad1322051e 6871847: AlgorithmId.get("SHA256withECDSA") not available Reviewed-by: vinnie ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/SHA256withECDSA.java Changeset: c34f92a47245 Author: darcy Date: 2009-09-04 13:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c34f92a47245 6873951: test/java/lang/reflect/Generics/Probe.java fails. Reviewed-by: alanb ! test/java/lang/reflect/Generics/Probe.java Changeset: 704296144175 Author: martin Date: 2009-09-04 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/704296144175 6879368: Remove stray quote in Character javadoc Summary: Remove stray quote in Character.valueOf javadoc, using Ulf's \u005CuXXXX technique Reviewed-by: darcy ! src/share/classes/java/lang/Character.java Changeset: 658a4255c797 Author: tbell Date: 2009-09-04 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/658a4255c797 Merge Changeset: 3f87b755b1c8 Author: alanb Date: 2009-09-04 18:15 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3f87b755b1c8 6873621: (file) FileStore.supportsFileAttributeView(Class type) returns wrong result Reviewed-by: andrew ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: 05ea733a7ae2 Author: alanb Date: 2009-09-04 18:17 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/05ea733a7ae2 6868627: (spec) Files.walkFileTree doesn't make it clear that uncaught errors and exceptions are propagated Reviewed-by: sherman ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java Changeset: 87a2ef2439bc Author: alanb Date: 2009-09-04 22:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/87a2ef2439bc 6432567: PIT : com/sun/jdi/BadHandshakeTest.java fails due to java.net.ConnectException Reviewed-by: tbell, ohair, dcubed, andrew ! src/share/transport/socket/socketTransport.c ! test/com/sun/jdi/BadHandshakeTest.java Changeset: 7afdf9d0bc2c Author: alanb Date: 2009-09-05 15:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7afdf9d0bc2c Merge Changeset: abb69e8b1774 Author: tbell Date: 2009-09-06 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/abb69e8b1774 Merge Changeset: 559fb14d0ae9 Author: anthony Date: 2009-08-27 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/559fb14d0ae9 6780496: Javaw process taking up 80-90 percent of CPU time! Summary: The transparency effects get enabled on showing, and disabled on hiding a window Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: 7599cca4fe5e Author: dcherepanov Date: 2009-08-27 17:04 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7599cca4fe5e 6852051: Getting Null Pointer Exception when displaying message for TrayIcon on Opensolaris Reviewed-by: anthony ! src/share/classes/java/awt/Component.java Changeset: 911a82b4901f Author: dcherepanov Date: 2009-08-27 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/911a82b4901f 6854898: Frame is located at the negative coordinates instead of origin for Solaris 10 CDE Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XErrorHandler.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: d5ac8fb96d13 Author: anthony Date: 2009-08-28 19:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d5ac8fb96d13 6689468: test/closed/java/awt/Component/VisibleHwInLwContTest/VisibleHwInLwContTest.html fails Summary: The addNotify() checks whether the component is actually hidden, and hides the peer appropriately if needed Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java Changeset: d755ace580b2 Author: yan Date: 2009-09-04 14:50 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d755ace580b2 6871299: Shift+Tab no longer generates a KEY_TYPED event; used to with JRE 1.5 Summary: Add XK_ISO_Left_Tab -> VK_TAB rule Reviewed-by: dcherepanov ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 5a584fbcc712 Author: yan Date: 2009-09-09 00:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5a584fbcc712 Merge Changeset: a48c15bcf64f Author: rupashka Date: 2009-08-14 13:18 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a48c15bcf64f 6824600: OOM occurs when setLookAndFeel() is executed in Windows L&F(XP style) Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalFontDesktopProperty.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java + test/com/sun/java/swing/plaf/windows/Test6824600.java Changeset: fa334ff12794 Author: alexp Date: 2009-08-19 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fa334ff12794 6872492: JLayer sources contain wrong header Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: 3e36c9abb569 Author: yan Date: 2009-08-20 23:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3e36c9abb569 Merge - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java Changeset: e8d93257cf7e Author: rupashka Date: 2009-08-21 16:59 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e8d93257cf7e 6579827: vista : JSlider on JColorchooser is not properly render or can't be seen completely. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6579827/bug6579827.java Changeset: d07bd8fa89e4 Author: rupashka Date: 2009-08-24 18:21 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d07bd8fa89e4 6849266: closed/javax/swing/JFileChooser/6484091/bug6484091.java fails on solaris 10 sparc Reviewed-by: peterz + test/javax/swing/JFileChooser/6484091/bug6484091.java Changeset: 799439873bf9 Author: alexp Date: 2009-08-24 19:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/799439873bf9 6824395: Several Swing core components prevent using them in wrapper classes Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JLayer/6824395/bug6824395.java ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 4914723317b9 Author: peytoia Date: 2009-08-31 12:55 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4914723317b9 6851214: (tz) New Jordan rule creates a failure for SimpleTimeZone parsing post tzdata2009h Reviewed-by: okutsu ! src/share/classes/java/util/SimpleTimeZone.java + test/java/util/TimeZone/ListTimeZones.java Changeset: 7aa6cb832991 Author: peytoia Date: 2009-08-31 14:50 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7aa6cb832991 6872467: (tz) Support tzdata2009l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab Changeset: 92b6482e7719 Author: peytoia Date: 2009-08-31 14:53 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/92b6482e7719 6456628: (tz) Default timezone is incorrectly set occasionally on Linux Reviewed-by: okutsu ! src/solaris/native/java/util/TimeZone_md.c Changeset: f7d606ca25a9 Author: peterz Date: 2009-08-31 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f7d606ca25a9 6802944: Nimbus initialization is too slow Reviewed-by: jasper ! make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/DerivedColor.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java Changeset: 7e7153da24ef Author: peterz Date: 2009-08-31 13:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7e7153da24ef 6844267: Nimbus generator depends on JIBX Summary: Nimbus generator now uses JAXB instead of JIBX Reviewed-by: jasper ! README ! make/common/Sanity.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/javax/swing/plaf/Makefile - make/javax/swing/plaf/nimbus/Makefile ! make/tools/Makefile + make/tools/generate_nimbus/Makefile + make/tools/src/build/tools/generatenimbus/Generator.java + make/tools/src/build/tools/generatenimbus/ObjectFactory.java + make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/PainterGenerator.java + make/tools/src/build/tools/generatenimbus/Shape.java + make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIStyle.java + make/tools/src/build/tools/generatenimbus/Utils.java - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: e7d311b4ae94 Author: alexp Date: 2009-08-31 18:39 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e7d311b4ae94 6872503: JLayer event handling should be rewritten Reviewed-by: art ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6872503/bug6872503.java Changeset: 9d8f551780d5 Author: peytoia Date: 2009-09-01 15:39 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9d8f551780d5 6830423: Unified Ext B character not displayed with Dialog font Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 37c33432e98a Author: peytoia Date: 2009-09-01 15:42 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/37c33432e98a 6838887: (tz) Add UTC and Yerevan to tzmappings Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: 5780cff2763c Author: peytoia Date: 2009-09-01 16:15 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5780cff2763c 6856390: RFE : sequence.allfonts.UTF-8.ja for Windows fontconfig.properties Reviewed-by: okutsu ! src/windows/classes/sun/awt/windows/fontconfig.properties Changeset: 4f819e2e0bfc Author: peterz Date: 2009-09-01 15:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4f819e2e0bfc 6387579: Usage of package-private class as parameter of a method (javax.swing.tree.DefaultTreeSelectionModel) Reviewed-by: rupashka ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 935814bd43a6 Author: alexp Date: 2009-09-01 18:51 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/935814bd43a6 6875153: JLayer.isOptimizedDrawingEnabled() throws NPE for null glass pane set Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/plaf/LayerUI.java + test/javax/swing/JLayer/6875153/bug6875153.java Changeset: 281fbd82a971 Author: alexp Date: 2009-09-02 17:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/281fbd82a971 6797139: JButton title is truncating for some strings irrespective of preferred size. Reviewed-by: peterz ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java ! src/share/classes/sun/swing/MenuItemLayoutHelper.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/SwingUtilities/6797139/bug6797139.java Changeset: ff468ef27959 Author: gsm Date: 2009-09-07 12:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ff468ef27959 6699856: Creating text in a JTextPane using Chinese text causes undesired behavior Reviewed-by: peterz ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 01c46cb72eb7 Author: rupashka Date: 2009-09-07 15:09 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/01c46cb72eb7 6589634: Unable to view focus on "Up one level", "create new folder" etc. of JFileChooser Dialog Reviewed-by: peterz, loneid ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: d73a741a7ea1 Author: malenkov Date: 2009-09-08 14:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d73a741a7ea1 6868185: 2 JCK api/java_beans/Introspector/ tests fails starting from jdk7 b66 Reviewed-by: peterz ! src/share/classes/com/sun/beans/finder/BeanInfoFinder.java Changeset: e289c06b6d36 Author: yan Date: 2009-09-09 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e289c06b6d36 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: 460639b036f3 Author: yan Date: 2009-09-15 23:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/460639b036f3 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java Changeset: f09a2bfba691 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f09a2bfba691 Added tag jdk7-b72 for changeset 460639b036f3 ! .hgtags From john.coomes at sun.com Thu Sep 17 22:03:42 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 18 Sep 2009 05:03:42 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 23 new changesets Message-ID: <20090918050421.025B91242F@hg.openjdk.java.net> Changeset: 40aca381dcaf Author: darcy Date: 2009-08-25 16:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/40aca381dcaf 6872011: Update printing processor to support JSR 308 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java Changeset: 25f15fdd168a Author: darcy Date: 2009-08-26 19:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/25f15fdd168a 6548708: Annotation processing should free service loader if there are no processors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 8109aa93b212 Author: mcimadamore Date: 2009-08-27 13:40 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8109aa93b212 6840638: Project Coin: Improved Type Inference for Generic Instance Creation (aka 'diamond') Summary: diamond operator implementation (simple approach) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/generics/diamond/neg/Neg01.java + test/tools/javac/generics/diamond/neg/Neg01.out + test/tools/javac/generics/diamond/neg/Neg02.java + test/tools/javac/generics/diamond/neg/Neg02.out + test/tools/javac/generics/diamond/neg/Neg03.java + test/tools/javac/generics/diamond/neg/Neg03.out + test/tools/javac/generics/diamond/neg/Neg04.java + test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/generics/diamond/neg/Neg05.java + test/tools/javac/generics/diamond/neg/Neg05.out + test/tools/javac/generics/diamond/pos/Pos01.java + test/tools/javac/generics/diamond/pos/Pos02.java + test/tools/javac/generics/diamond/pos/Pos03.java + test/tools/javac/generics/diamond/pos/Pos04.java Changeset: ed31953ca025 Author: jjg Date: 2009-08-27 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ed31953ca025 6875336: some tests should use /nodynamiccopyright/ Reviewed-by: darcy ! test/tools/javac/6521805/T6521805a.java ! test/tools/javac/6521805/T6521805a_1.out ! test/tools/javac/6521805/T6521805a_2.out ! test/tools/javac/6521805/T6521805d.java ! test/tools/javac/6521805/T6521805d.out ! test/tools/javac/6717241/T6717241a.java ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.java ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6734819/T6734819c.java ! test/tools/javac/6734819/T6734819c.out ! test/tools/javac/6758789/T6758789a.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6758789/T6758789b.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/6840059/T6840059.java ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/Diagnostics/6722234/T6722234a.java ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b.java ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.java ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.java ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6860795/T6860795.java ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/Diagnostics/6862608/T6862608a.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.java ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/Diagnostics/6864382/T6864382.java ! test/tools/javac/Diagnostics/6864382/T6864382.out ! test/tools/javac/OverrideChecks/6199153/T6199153.java ! test/tools/javac/OverrideChecks/6199153/T6199153.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.java ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.java ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/cast/6467183/T6467183a.java ! test/tools/javac/cast/6467183/T6467183a.out ! test/tools/javac/cast/6557182/T6557182.java ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.java ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.java ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/generics/5009937/T5009937.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950a.java ! test/tools/javac/generics/6182950/T6182950a.out ! test/tools/javac/generics/6182950/T6182950b.java ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6677785/T6677785.java ! test/tools/javac/generics/6677785/T6677785.out ! test/tools/javac/generics/6711619/T6711619a.java ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/6711619/T6711619b.java ! test/tools/javac/generics/6711619/T6711619b.out ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/6723444/T6723444.out ! test/tools/javac/generics/inference/6315770/T6315770.java ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.java ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.java ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.java ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6718364/T6718364.java ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/rare/6665356/T6665356.java ! test/tools/javac/generics/rare/6665356/T6665356.out ! test/tools/javac/generics/typevars/6569404/T6569404b.java ! test/tools/javac/generics/typevars/6569404/T6569404b.out ! test/tools/javac/generics/typevars/6680106/T6680106.java ! test/tools/javac/generics/typevars/6680106/T6680106.out ! test/tools/javac/generics/typevars/6804733/T6804733.java ! test/tools/javac/generics/typevars/6804733/T6804733.out ! test/tools/javac/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/typeAnnotations/failures/IncompleteArray.out ! test/tools/javac/typeAnnotations/failures/IncompleteVararg.java ! test/tools/javac/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/typeAnnotations/failures/IndexArray.java ! test/tools/javac/typeAnnotations/failures/IndexArray.out ! test/tools/javac/typeAnnotations/failures/LintCast.java ! test/tools/javac/typeAnnotations/failures/LintCast.out ! test/tools/javac/typeAnnotations/failures/Scopes.java ! test/tools/javac/typeAnnotations/failures/Scopes.out ! test/tools/javac/typeAnnotations/failures/StaticFields.java ! test/tools/javac/typeAnnotations/failures/StaticFields.out ! test/tools/javac/typeAnnotations/failures/StaticMethods.java ! test/tools/javac/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/arrays/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/newarray/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/receiver/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/rest/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/rest/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/InvalidLocation.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/target/Constructor.java ! test/tools/javac/typeAnnotations/failures/target/Constructor.out ! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.java ! test/tools/javac/typeAnnotations/failures/target/IncompleteArray.out ! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.java ! test/tools/javac/typeAnnotations/failures/target/NotTypeParameter.out ! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.java ! test/tools/javac/typeAnnotations/failures/target/NotTypeUse.out ! test/tools/javac/typeAnnotations/failures/target/VoidMethod.java ! test/tools/javac/typeAnnotations/failures/target/VoidMethod.out ! test/tools/javac/varargs/6806876/T6806876.java ! test/tools/javac/varargs/6806876/T6806876.out ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 74760fd5197f Author: jjg Date: 2009-08-27 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/74760fd5197f 6843707: bad tests generate files in the test/ directory 6876699: generated files in repository Reviewed-by: darcy - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java ! test/tools/javac/meth/MakeNegTests.sh ! test/tools/javac/quid/MakeNegTests.sh - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: 2c20f17c429c Author: jjg Date: 2009-08-27 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2c20f17c429c 6876753: javap tests fail on Windows Reviewed-by: darcy ! test/tools/javap/T4975569.java ! test/tools/javap/T6729471.java ! test/tools/javap/pathsep.sh ! test/tools/javap/stackmap/T6271292.sh Changeset: f29068bfeaed Author: jjg Date: 2009-08-27 17:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/f29068bfeaed 6876755: apt tests fail on Windows Reviewed-by: darcy ! test/tools/apt/Basics/apt.sh ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh Changeset: 477c5bf1149c Author: jjg Date: 2009-08-27 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/477c5bf1149c 6876765: javah tests fail on Windows Reviewed-by: darcy ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh Changeset: 0ba956343648 Author: jjg Date: 2009-08-28 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/0ba956343648 6876782: two javadoc tests fail on Windows Reviewed-by: darcy ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java Changeset: f0c9fc46990b Author: jjg Date: 2009-08-28 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/f0c9fc46990b 6877188: some javac shell tests do not work on Windows Reviewed-by: darcy ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh Changeset: ce5be4c09f2a Author: tbell Date: 2009-08-28 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/ce5be4c09f2a Merge - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: d5e76d422509 Author: jjg Date: 2009-08-31 12:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/d5e76d422509 6877229: more javac tests fail on Windows Reviewed-by: darcy ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/MissingInclude.sh ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java ! test/tools/javac/code/ArrayClone.java ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/quid/QuotedIdent.java ! test/tools/javac/quid/QuotedIdent2.java ! test/tools/javac/stackmap/T4955930.sh Changeset: 4fa458c945ac Author: jjg Date: 2009-08-31 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4fa458c945ac 6877744: delete extraneous file Reviewed-by: darcy - test/tools/javac/innerClassFile/Driver.java Changeset: 45301370bc5a Author: jjg Date: 2009-08-31 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/45301370bc5a 6877751: test/tools/javac/6627362/T6627362.java fails Reviewed-by: darcy ! test/tools/javac/6627362/T6627362.java Changeset: 5a72ba18c471 Author: jjg Date: 2009-08-31 19:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/5a72ba18c471 6877759: test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java leaves open file Reviewed-by: darcy ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Changeset: dda7e13f09fb Author: mcimadamore Date: 2009-09-01 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/dda7e13f09fb 6650759: Inference of formal type parameter (unused in formal parameters) is not performed Summary: propagate inference constraints from 15.12.2.7 to 15.12.2.8 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/generics/inference/6302954/T6476073.java ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712e.out + test/tools/javac/generics/inference/6650759/T6650759a.java + test/tools/javac/generics/inference/6650759/T6650759b.java + test/tools/javac/generics/inference/6650759/T6650759c.java + test/tools/javac/generics/inference/6650759/T6650759d.java + test/tools/javac/generics/inference/6650759/T6650759e.java + test/tools/javac/generics/inference/6650759/T6650759f.java + test/tools/javac/generics/inference/6650759/T6650759g.java + test/tools/javac/generics/inference/6650759/T6650759h.java + test/tools/javac/generics/inference/6650759/T6650759i.java + test/tools/javac/generics/inference/6650759/T6650759j.java + test/tools/javac/generics/inference/6650759/T6650759k.java + test/tools/javac/generics/inference/6650759/T6650759l.java + test/tools/javac/generics/inference/6650759/T6650759m.java + test/tools/javac/generics/inference/6650759/T6650759m.out Changeset: 40a1327a5283 Author: jjg Date: 2009-09-01 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/40a1327a5283 6877763: update langtools/test/Makefile for JPRT Reviewed-by: ohair ! test/Makefile Changeset: 8d999cb7ec09 Author: jjg Date: 2009-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8d999cb7ec09 6874249: Check has duplicate local variable and field for "source" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java Changeset: 90c28923e449 Author: tbell Date: 2009-09-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/90c28923e449 Merge - test/tools/javac/innerClassFile/Driver.java - test/tools/javac/meth/InvokeMH_BAD68.java - test/tools/javac/meth/InvokeMH_BAD72.java - test/tools/javac/quid/QuotedIdent_BAD61.java - test/tools/javac/quid/QuotedIdent_BAD62.java - test/tools/javac/quid/QuotedIdent_BAD63.java Changeset: 35e29f51a7c3 Author: jjg Date: 2009-09-08 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/35e29f51a7c3 6419701: DefaultFileManager clean up: URI.create 6483788: DefaultFileManager.ZipFileObject.toUri() fails to escape space characters 6501502: JSR 199: FileObject.toUri should return file:///c:/ or file:/c:/ not file://c:/ 6877206: JavaFileObject.toUri returns bogus URI (win) 6877223: tests @ignored because of issues with File.toURI on Windows Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! test/tools/javac/Diagnostics/6769027/tester.properties ! test/tools/javac/api/6440333/T6440333.java ! test/tools/javac/api/Sibling.java + test/tools/javac/api/T6483788.java + test/tools/javac/api/T6501502.java + test/tools/javac/api/T6877206.java Changeset: dd98acd9f717 Author: jjg Date: 2009-09-08 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/dd98acd9f717 6879346: files have Windows newlines Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testCRLineSeparator/pkg/MyClass.java ! test/com/sun/javadoc/testHref/package-list ! test/com/sun/javadoc/testLinkOption/testNewLineInLink/package.html ! test/com/sun/javadoc/testNoPackagesFile/TestNoPackagesFile.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testRelativeLinks/pkg/package.html ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testWarnings/pkg/package.html ! test/tools/javah/SubClassConsts.win Changeset: 261c54b2312e Author: jjg Date: 2009-09-08 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/261c54b2312e 6879371: javap does not close internal default file manager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6879371.java Changeset: bfad32768345 Author: xdono Date: 2009-09-17 13:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/bfad32768345 Added tag jdk7-b72 for changeset 261c54b2312e ! .hgtags From andrey.petrusenko at sun.com Fri Sep 18 10:22:52 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 18 Sep 2009 17:22:52 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 12 new changesets Message-ID: <20090918172320.38AA7124F2@hg.openjdk.java.net> Changeset: 489a4f8dcd0f Author: twisti Date: 2009-08-27 06:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/489a4f8dcd0f 6865583: Verbose CIPrintMethodCodes asserts when ldc an empty String Summary: ldc seems to load an empty String and that leads to an assert on offset < length, which are both zero. Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp Changeset: 8fe1963e3964 Author: kvn Date: 2009-08-28 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8fe1963e3964 6875577: CTW fails with /hotspot/src/share/vm/opto/memnode.cpp Summary: Fix do_null_check to check for unloaded klass for all oop pointers. Reviewed-by: never, cfang ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp Changeset: 1fbd5d696bf4 Author: twisti Date: 2009-08-31 02:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1fbd5d696bf4 6875967: CTW fails with./generated/adfiles/ad_sparc.cpp:6711 Reviewed-by: cfang, never ! src/cpu/sparc/vm/sparc.ad Changeset: ace8397c8563 Author: cfang Date: 2009-08-31 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ace8397c8563 6876276: assert(!is_visited,"visit only once") Summary: schedule the superword loads based on dependence constraints Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: ff1a29907b6c Author: never Date: 2009-08-31 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ff1a29907b6c 6855215: Calculation error (NaN) after about 1500 calculations Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp + test/compiler/6855215/Test6855215.java Changeset: 0f1c19b7a52d Author: kvn Date: 2009-09-08 10:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0f1c19b7a52d 6875619: CTW fails with /hotspot/src/share/vm/opto/type.hpp Summary: In load_array_length() cast array's type to TypeOopPtr when calling make_ideal_length() method. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 26fbe81d30cf Author: kvn Date: 2009-09-08 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/26fbe81d30cf 6880052: SIGSEGV in GraphKit::null_check_common() Summary: Check that a klass is not NULL before the is_loaded() call. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 9a4e87ba1a90 Author: kvn Date: 2009-09-09 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9a4e87ba1a90 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Summary: Add missing test option -XX:+IgnoreUnrecognizedVMOptions. Reviewed-by: never ! test/compiler/6865031/Test.java Changeset: 159d56b94894 Author: kvn Date: 2009-09-10 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/159d56b94894 6880574: C2 assert in escape.cpp:445 on linux-amd64 Summary: Look through chained AddP nodes in get_addp_base(). Reviewed-by: jrose ! src/share/vm/opto/escape.cpp Changeset: c7e94e8fff43 Author: kvn Date: 2009-09-10 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c7e94e8fff43 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and use MembarCPUOrder after arraycopy to cloned object. Reviewed-by: never ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: a6f533fc33e0 Author: kvn Date: 2009-09-14 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a6f533fc33e0 Merge Changeset: d7c9544cc141 Author: apetrusenko Date: 2009-09-18 06:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d7c9544cc141 Merge From John.Coomes at sun.com Mon Sep 21 10:09:25 2009 From: John.Coomes at sun.com (John Coomes) Date: Mon, 21 Sep 2009 10:09:25 -0700 Subject: review request (L) - 6423256 GC stacks Message-ID: <19127.45893.964149.754611@sun.com> I'd appreciate reviews of 6423256: GC stacks should use a better data structure http://cr.openjdk.java.net/~jcoomes/6423256-gc-stacks/ See the comments at the top of the webrev and in file stack.hpp for some hints/details. -John From Jon.Masamitsu at Sun.COM Tue Sep 22 13:56:12 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 22 Sep 2009 13:56:12 -0700 Subject: Question on ParallelGCThreads In-Reply-To: <19B27FD5AF2EAA49A66F787911CF519596D051@CTSINCHNSXUU.cts.com> References: <19B27FD5AF2EAA49A66F787911CF519596D051@CTSINCHNSXUU.cts.com> Message-ID: <4AB939EC.2070206@Sun.COM> On 09/22/09 12:46, Sujit.Das at cognizant.com wrote: > Hi All, > > We use CMS collector for old generation collection (option > -XX:+UseConcMarkSweepGC) and parallel copying collector for young > generation (option -XX:+ UseParNewGC). We use ParallelGCThreads command > line option (-XX:ParallelGCThreads=) to control number > of garbage collector threads. > > My question is: > 1. Is ParallelGCThreads option applicable for only minor GC or is it > applicable for old generation GC also? Parts of the old generation collection that stop-the-world and do work with multiple GC threads also use ParallelGCThreads. This would be the initial-mark and remark phases assuming you're using a recent release (parallel initial-mark and parallel remark were not in the first release of CMS). Additionally, the concurrent marking that uses multiple GC threads (introduced in jdk6) may be affected by ParallelGCThreads. The number of GC threads used in the concurrent marking is a fraction of ParallelGCThreads. > > 2. Since CMS collector is a non-compacting collector and if application > faces memory fragmentation issue then reducing # of ParallelGCThreads is > an option to reduce fragmentation. Please confirm the understanding. > This is based on my reading that each garbage collection thread reserves > a part of the old generation for promotions and the division of the > available space into these "promotion buffers" can cause a fragmentation > effect. Reducing the number of garbage collector threads will reduce > this fragmentation effect as will increasing the size of the old > generation. Yes, the promotion-local-allocation-buffers (PLAB's) can fragment the old generation although that is not the most common cause. There might have been an investigation of this type of fragmentation recently. I'll ask around. Increasing the size of the old gen ameliorates the affects of fragmentation by giving objects more time to die and allows CMS more time to coalesce dead space into larger blocks. > > Thanks, > Sujit > > This e-mail and any files transmitted with it are for the sole use of > the intended recipient(s) and may contain confidential and privileged > information. > If you are not the intended recipient, please contact the sender by > reply e-mail and destroy all copies of the original message. > Any unauthorized review, use, disclosure, dissemination, forwarding, > printing or copying of this email or any action taken in reliance on > this e-mail is strictly prohibited and may be unlawful. > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From y.s.ramakrishna at sun.com Wed Sep 23 16:14:55 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Wed, 23 Sep 2009 23:14:55 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6884552: remove some unnecessary #ifdef's introduced in the fix for 4957990 Message-ID: <20090923231501.993F41284D@hg.openjdk.java.net> Changeset: c3c4a1d3801a Author: andrew Date: 2009-09-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c3c4a1d3801a 6884552: remove some unnecessary #ifdef's introduced in the fix for 4957990 Summary: Removed the unnecessary #ifdef's which were interfering with the build of the Zero-assembler port Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp From andrey.petrusenko at sun.com Fri Sep 25 07:44:20 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Fri, 25 Sep 2009 14:44:20 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 19 new changesets Message-ID: <20090925144505.BF41C12915@hg.openjdk.java.net> Changeset: aafa4232dfd7 Author: asaha Date: 2009-08-28 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/aafa4232dfd7 6821003: Update hotspot windows os_win32 for windows 7 Reviewed-by: xlu ! src/os/windows/vm/os_windows.cpp Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: 75e30968ebe1 Author: dcubed Date: 2009-08-28 12:32 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/75e30968ebe1 Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: df97b1cf46d8 Author: dcubed Date: 2009-08-28 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/df97b1cf46d8 Merge Changeset: bb287c042e99 Author: apangin Date: 2009-08-30 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bb287c042e99 Merge Changeset: 6918603297f7 Author: poonam Date: 2009-09-01 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6918603297f7 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Summary: Add an explicit check for TypeProfileWidth == 0 in record_klass_in_profile_helper() functions. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 5fdbe2cdf565 Author: andrew Date: 2009-09-08 09:01 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5fdbe2cdf565 6879689: Fix warning about ignored return value when compiling with -O2 Summary: Store the return value of fwrite and check it matches the size of the array. Reviewed-by: twisti, dholmes ! src/share/vm/adlc/archDesc.cpp Changeset: 0804a88ed4f5 Author: andrew Date: 2009-09-08 09:02 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0804a88ed4f5 Merge Changeset: 682194ca1d8d Author: acorn Date: 2009-09-10 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/682194ca1d8d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 0fc81f0a8ca8 Author: andrew Date: 2009-09-12 12:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0fc81f0a8ca8 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/jvmti.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/projectfiles/common/Makefile Changeset: e5b31fd85b72 Author: acorn Date: 2009-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e5b31fd85b72 Merge Changeset: ad6585fd4087 Author: acorn Date: 2009-09-04 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ad6585fd4087 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26b774d693aa Author: acorn Date: 2009-09-16 09:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/26b774d693aa Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp Changeset: 83c29a26f67c Author: acorn Date: 2009-09-16 15:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/83c29a26f67c 6879572: SA fails _is_marked_dependent not found Reviewed-by: kamg, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 723131383de6 Author: acorn Date: 2009-09-18 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/723131383de6 Merge Changeset: 74a5db69c1fe Author: dcubed Date: 2009-09-21 09:30 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/74a5db69c1fe 6419370: 4/4 new jmethodID code has tiny holes in synchronization Summary: Fix races in jmethodID cache and JNI itable index cache. Reviewed-by: ikrylov, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp Changeset: d72ba3205918 Author: acorn Date: 2009-09-21 18:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d72ba3205918 Merge Changeset: 87770dcf831b Author: dcubed Date: 2009-09-22 21:12 -0600 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/87770dcf831b 6876794: 4/4 sp07t002 hangs very intermittently Summary: remove over locking by VMThread on "is thread suspended?" check Reviewed-by: dholmes, acorn, andrew ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 1af62b6ca0f9 Author: apetrusenko Date: 2009-09-25 04:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1af62b6ca0f9 Merge From tony.printezis at sun.com Fri Sep 25 09:14:00 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 25 Sep 2009 12:14:00 -0400 Subject: CRR: 6885041: G1: inconsistent thread dump (XS) Message-ID: <4ABCEC48.70304@sun.com> Small changes to get the thread dump information for the G1 threads consistent with what other GCs do. The webrev is here: http://cr.openjdk.java.net/~tonyp/6885041/webrev.0/ Tony -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From tony.printezis at sun.com Fri Sep 25 10:28:32 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 25 Sep 2009 13:28:32 -0400 Subject: CRR: 6882730: G1: parallel heap verification messes up region dump Message-ID: <4ABCFDC0.8080207@sun.com> The webrev is here: http://cr.openjdk.java.net/~tonyp/6882730/webrev.0/ In the fix, I just propagate the fact that heap verification failed all the way to the top-level ::verify call and dump the heap there, where it is guaranteed to be single-threaded. I also added a couple of cosmetic changes to the heap dump. Tony -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From tony.printezis at sun.com Fri Sep 25 12:55:27 2009 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 25 Sep 2009 15:55:27 -0400 Subject: CRR: 6885041: G1: inconsistent thread dump (XS) In-Reply-To: <4ABCEC48.70304@sun.com> References: <4ABCEC48.70304@sun.com> Message-ID: <4ABD202F.1040201@sun.com> Thanks to Ramki for his comments. I tidied up the code bit: http://cr.openjdk.java.net/~tonyp/6885041/webrev.1/ Tony Tony Printezis wrote: > Small changes to get the thread dump information for the G1 threads > consistent with what other GCs do. The webrev is here: > > http://cr.openjdk.java.net/~tonyp/6885041/webrev.0/ > > Tony > -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From shane.cox at gmail.com Mon Sep 28 10:07:09 2009 From: shane.cox at gmail.com (Shane Cox) Date: Mon, 28 Sep 2009 13:07:09 -0400 Subject: unexplained CMS pauses Message-ID: Our application is reporting long pauses when a minor GC occurs during the Concurrent Mark phase of CMS. The output below is a specific example. All of the GC pauses are less than 30ms (initial mark, remark, minor GC). However, our app reported a 300ms pause. 56750.934: [GC [1 CMS-initial-mark: 702464K(1402496K)] 719045K(1551616K), 0.0131859 secs] 56750.947: [CMS-concurrent-mark-start] 56752.133: [GC 56752.133: [ParNew: 144393K->12122K(149120K), 0.0237615 secs] 846857K->719330K(1551616K), 0.0239988 secs] 56752.162: [CMS-concurrent-mark: 1.188/1.215 secs] 56752.162: [CMS-concurrent-preclean-start] 56752.243: [CMS-concurrent-preclean: 0.070/0.081 secs] 56752.243: [CMS-concurrent-abortable-preclean-start] 56752.765: [CMS-concurrent-abortable-preclean: 0.143/0.522 secs] 56752.766: [GC[YG occupancy: 77423 K (149120 K)]56752.766: [Rescan (parallel) , 0.0065730 secs]56752.773: [weak refs processing, 0.0001983 secs] [1 CMS-remark: 707208K(1402496K)] 784631K(1551616K), 0.0068908 secs] 56752.773: [CMS-concurrent-sweep-start] 56753.209: [CMS-concurrent-sweep: 0.436/0.436 secs] 56753.209: [CMS-concurrent-reset-start] 56753.219: [CMS-concurrent-reset: 0.010/0.010 secs] We only observe this behavior when a minor GC occurs during the Concurrent Mark (which is rare). Our app has reported pauses up to 1.2 seconds ... which is generally the time it takes to perform a Concurrent Mark. Any insight/help that you could provide would be much appreciated. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090928/9a644523/attachment.html From Y.S.Ramakrishna at Sun.COM Mon Sep 28 10:13:18 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 28 Sep 2009 10:13:18 -0700 Subject: unexplained CMS pauses In-Reply-To: References: Message-ID: <4AC0EEAE.5010705@Sun.COM> What platform are you on (#cpu's etc.) and when you say "app reports a pause of 300 ms" is it that the odd transaction sees a latency of 300 ms (coincident with concurrent mark), whereas most transactions complete much more quickly? I am trying to first understand how you determine that the application is seeing "long pauses" when a minor gc occurs during concurrent mark. PS: for example, if two gc pauses (say a scavenge of 30 ms and an initial mark of 13 ms occur in quick succession, your application might notice a pause of 43 ms, etc.) -- ramki On 09/28/09 10:07, Shane Cox wrote: > Our application is reporting long pauses when a minor GC occurs during > the Concurrent Mark phase of CMS. The output below is a specific > example. All of the GC pauses are less than 30ms (initial mark, remark, > minor GC). However, our app reported a 300ms pause. > > 56750.934: [GC [1 CMS-initial-mark: 702464K(1402496K)] > 719045K(1551616K), 0.0131859 secs] > 56750.947: [CMS-concurrent-mark-start] > 56752.133: [GC 56752.133: [ParNew: 144393K->12122K(149120K), 0.0237615 > secs] 846857K->719330K(1551616K), 0.0239988 secs] > 56752.162: [CMS-concurrent-mark: 1.188/1.215 secs] > 56752.162: [CMS-concurrent-preclean-start] > 56752.243: [CMS-concurrent-preclean: 0.070/0.081 secs] > 56752.243: [CMS-concurrent-abortable-preclean-start] > 56752.765: [CMS-concurrent-abortable-preclean: 0.143/0.522 secs] > 56752.766: [GC[YG occupancy: 77423 K (149120 K)]56752.766: [Rescan > (parallel) , 0.0065730 secs]56752.773: [weak refs processing, 0.0001983 > secs] [1 CMS-remark: 707208K(1402496K)] 784631K(1551616K), 0.0068908 secs] > 56752.773: [CMS-concurrent-sweep-start] > 56753.209: [CMS-concurrent-sweep: 0.436/0.436 secs] > 56753.209: [CMS-concurrent-reset-start] > 56753.219: [CMS-concurrent-reset: 0.010/0.010 secs] > > > We only observe this behavior when a minor GC occurs during the > Concurrent Mark (which is rare). Our app has reported pauses up to 1.2 > seconds ... which is generally the time it takes to perform a Concurrent > Mark. > > > Any insight/help that you could provide would be much appreciated. > > Thanks From shane.cox at gmail.com Mon Sep 28 11:06:19 2009 From: shane.cox at gmail.com (Shane Cox) Date: Mon, 28 Sep 2009 14:06:19 -0400 Subject: unexplained CMS pauses In-Reply-To: <4AC0EEAE.5010705@Sun.COM> References: <4AC0EEAE.5010705@Sun.COM> Message-ID: Ramki, We're running Solaris 10 on 8-core Intel Xeon's. 1 Java instance per box. JRE 1.6, update 14. 64-bit JVM. Our app is making JNI calls. Each call requires approximately the same amount of work (so we expect them to perform similarly). Internally, we measure how long it takes to perform these calls. +99% of these calls complete in less than 100 micros. However, we have outliers in the 300-1200ms range. After some research, we have found that these extreme outliers coincide with the Concurrent Mark phase of CMS (based on timestamps), and ONLY if there is a minor GC during that phase. In a given day, our app will execute CMS collections 500-1000 times. Of these, less than 10 will have a minor collection execute during the Concurrent Mark. For each of these, our app reports a large pause in the 300-1200ms range. In fact, all of the large pauses reported by our app correlate with a minor GC during a Concurrent Mark, without exception. Thanks On Mon, Sep 28, 2009 at 1:13 PM, wrote: > What platform are you on (#cpu's etc.) > and when you say "app reports a pause of 300 ms" > is it that the odd transaction sees a latency > of 300 ms (coincident with concurrent mark), > whereas most transactions complete much more > quickly? > > I am trying to first understand how you determine > that the application is seeing "long pauses" > when a minor gc occurs during concurrent mark. > > PS: for example, if two gc pauses (say a scavenge of 30 ms > and an initial mark of 13 ms occur in quick succession, > your application might notice a pause of 43 ms, etc.) > > -- ramki > > > On 09/28/09 10:07, Shane Cox wrote: > >> Our application is reporting long pauses when a minor GC occurs during the >> Concurrent Mark phase of CMS. The output below is a specific example. All >> of the GC pauses are less than 30ms (initial mark, remark, minor GC). >> However, our app reported a 300ms pause. >> >> 56750.934: [GC [1 CMS-initial-mark: 702464K(1402496K)] 719045K(1551616K), >> 0.0131859 secs] >> 56750.947: [CMS-concurrent-mark-start] >> 56752.133: [GC 56752.133: [ParNew: 144393K->12122K(149120K), 0.0237615 >> secs] 846857K->719330K(1551616K), 0.0239988 secs] >> 56752.162: [CMS-concurrent-mark: 1.188/1.215 secs] >> 56752.162: [CMS-concurrent-preclean-start] >> 56752.243: [CMS-concurrent-preclean: 0.070/0.081 secs] >> 56752.243: [CMS-concurrent-abortable-preclean-start] >> 56752.765: [CMS-concurrent-abortable-preclean: 0.143/0.522 secs] >> 56752.766: [GC[YG occupancy: 77423 K (149120 K)]56752.766: [Rescan >> (parallel) , 0.0065730 secs]56752.773: [weak refs processing, 0.0001983 >> secs] [1 CMS-remark: 707208K(1402496K)] 784631K(1551616K), 0.0068908 secs] >> 56752.773: [CMS-concurrent-sweep-start] >> 56753.209: [CMS-concurrent-sweep: 0.436/0.436 secs] >> 56753.209: [CMS-concurrent-reset-start] >> 56753.219: [CMS-concurrent-reset: 0.010/0.010 secs] >> >> >> We only observe this behavior when a minor GC occurs during the Concurrent >> Mark (which is rare). Our app has reported pauses up to 1.2 seconds ... >> which is generally the time it takes to perform a Concurrent Mark. >> >> >> Any insight/help that you could provide would be much appreciated. >> >> Thanks >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090928/e9cbebb9/attachment.html From Paul.Hohensee at Sun.COM Mon Sep 28 16:24:30 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 28 Sep 2009 19:24:30 -0400 Subject: unexplained CMS pauses In-Reply-To: References: <4AC0EEAE.5010705@Sun.COM> Message-ID: <4AC145AE.30804@sun.com> Might have nothing to do with concurrent mark running, rather with minor collections happening during a java->native call. Minor collections are stop-the-world, and if one occurs during a java->native call, the java thread making the call to native will block on return from the call to native until the minor collection is over. If the outliers are outliers in the time it takes to execute the native call, and the minor gc duration and timing are exactly right, you could end up spending most of the minor gc time blocked. Pause time would then be 100ms + minor gc time. Paul Shane Cox wrote: > Ramki, > We're running Solaris 10 on 8-core Intel Xeon's. 1 Java instance per > box. JRE 1.6, update 14. 64-bit JVM. > > Our app is making JNI calls. Each call requires approximately the > same amount of work (so we expect them to perform similarly). > Internally, we measure how long it takes to perform these calls. +99% > of these calls complete in less than 100 micros. However, we have > outliers in the 300-1200ms range. After some research, we have found > that these extreme outliers coincide with the Concurrent Mark phase of > CMS (based on timestamps), and ONLY if there is a minor GC during that > phase. > > In a given day, our app will execute CMS collections 500-1000 times. > Of these, less than 10 will have a minor collection execute during the > Concurrent Mark. For each of these, our app reports a large pause in > the 300-1200ms range. In fact, all of the large pauses reported by > our app correlate with a minor GC during a Concurrent Mark, without > exception. > > Thanks > > On Mon, Sep 28, 2009 at 1:13 PM, > wrote: > > What platform are you on (#cpu's etc.) > and when you say "app reports a pause of 300 ms" > is it that the odd transaction sees a latency > of 300 ms (coincident with concurrent mark), > whereas most transactions complete much more > quickly? > > I am trying to first understand how you determine > that the application is seeing "long pauses" > when a minor gc occurs during concurrent mark. > > PS: for example, if two gc pauses (say a scavenge of 30 ms > and an initial mark of 13 ms occur in quick succession, > your application might notice a pause of 43 ms, etc.) > > -- ramki > > > On 09/28/09 10:07, Shane Cox wrote: > > Our application is reporting long pauses when a minor GC > occurs during the Concurrent Mark phase of CMS. The output > below is a specific example. All of the GC pauses are less > than 30ms (initial mark, remark, minor GC). However, our app > reported a 300ms pause. > > 56750.934: [GC [1 CMS-initial-mark: 702464K(1402496K)] > 719045K(1551616K), 0.0131859 secs] > 56750.947: [CMS-concurrent-mark-start] > 56752.133: [GC 56752.133: [ParNew: 144393K->12122K(149120K), > 0.0237615 secs] 846857K->719330K(1551616K), 0.0239988 secs] > 56752.162: [CMS-concurrent-mark: 1.188/1.215 secs] > 56752.162: [CMS-concurrent-preclean-start] > 56752.243: [CMS-concurrent-preclean: 0.070/0.081 secs] > 56752.243: [CMS-concurrent-abortable-preclean-start] > 56752.765: [CMS-concurrent-abortable-preclean: 0.143/0.522 secs] > 56752.766: [GC[YG occupancy: 77423 K (149120 K)]56752.766: > [Rescan (parallel) , 0.0065730 secs]56752.773: [weak refs > processing, 0.0001983 secs] [1 CMS-remark: 707208K(1402496K)] > 784631K(1551616K), 0.0068908 secs] > 56752.773: [CMS-concurrent-sweep-start] > 56753.209: [CMS-concurrent-sweep: 0.436/0.436 secs] > 56753.209: [CMS-concurrent-reset-start] > 56753.219: [CMS-concurrent-reset: 0.010/0.010 secs] > > > We only observe this behavior when a minor GC occurs during > the Concurrent Mark (which is rare). Our app has reported > pauses up to 1.2 seconds ... which is generally the time it > takes to perform a Concurrent Mark. > > > Any insight/help that you could provide would be much appreciated. > > Thanks > > > From Y.S.Ramakrishna at Sun.COM Mon Sep 28 16:37:26 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 28 Sep 2009 16:37:26 -0700 Subject: unexplained CMS pauses In-Reply-To: <4AC145AE.30804@sun.com> References: <4AC0EEAE.5010705@Sun.COM> <4AC145AE.30804@sun.com> Message-ID: <4AC148B6.7010608@Sun.COM> Hi Paul, that would be 100 us + minor gc time (=30 ms) = 30.1 ms. It does not explain the 10- to 40-fold increase in txn times observed here (of 300 ms - 1200 ms). -- ramki On 09/28/09 16:24, Paul Hohensee wrote: > Might have nothing to do with concurrent mark running, rather with minor > collections > happening during a java->native call. > > Minor collections are stop-the-world, and if one occurs during a > java->native call, the > java thread making the call to native will block on return from the call > to native until > the minor collection is over. If the outliers are outliers in the time > it takes to execute > the native call, and the minor gc duration and timing are exactly right, > you could end > up spending most of the minor gc time blocked. Pause time would then be > 100ms > + minor gc time. > > Paul > > Shane Cox wrote: >> Ramki, >> We're running Solaris 10 on 8-core Intel Xeon's. 1 Java instance per >> box. JRE 1.6, update 14. 64-bit JVM. >> >> Our app is making JNI calls. Each call requires approximately the >> same amount of work (so we expect them to perform similarly). >> Internally, we measure how long it takes to perform these calls. +99% >> of these calls complete in less than 100 micros. However, we have >> outliers in the 300-1200ms range. After some research, we have found >> that these extreme outliers coincide with the Concurrent Mark phase of >> CMS (based on timestamps), and ONLY if there is a minor GC during that >> phase. >> >> In a given day, our app will execute CMS collections 500-1000 times. >> Of these, less than 10 will have a minor collection execute during the >> Concurrent Mark. For each of these, our app reports a large pause in >> the 300-1200ms range. In fact, all of the large pauses reported by >> our app correlate with a minor GC during a Concurrent Mark, without >> exception. >> >> Thanks >> >> On Mon, Sep 28, 2009 at 1:13 PM, > > wrote: >> >> What platform are you on (#cpu's etc.) >> and when you say "app reports a pause of 300 ms" >> is it that the odd transaction sees a latency >> of 300 ms (coincident with concurrent mark), >> whereas most transactions complete much more >> quickly? >> >> I am trying to first understand how you determine >> that the application is seeing "long pauses" >> when a minor gc occurs during concurrent mark. >> >> PS: for example, if two gc pauses (say a scavenge of 30 ms >> and an initial mark of 13 ms occur in quick succession, >> your application might notice a pause of 43 ms, etc.) >> >> -- ramki >> >> >> On 09/28/09 10:07, Shane Cox wrote: >> >> Our application is reporting long pauses when a minor GC >> occurs during the Concurrent Mark phase of CMS. The output >> below is a specific example. All of the GC pauses are less >> than 30ms (initial mark, remark, minor GC). However, our app >> reported a 300ms pause. >> >> 56750.934: [GC [1 CMS-initial-mark: 702464K(1402496K)] >> 719045K(1551616K), 0.0131859 secs] >> 56750.947: [CMS-concurrent-mark-start] >> 56752.133: [GC 56752.133: [ParNew: 144393K->12122K(149120K), >> 0.0237615 secs] 846857K->719330K(1551616K), 0.0239988 secs] >> 56752.162: [CMS-concurrent-mark: 1.188/1.215 secs] >> 56752.162: [CMS-concurrent-preclean-start] >> 56752.243: [CMS-concurrent-preclean: 0.070/0.081 secs] >> 56752.243: [CMS-concurrent-abortable-preclean-start] >> 56752.765: [CMS-concurrent-abortable-preclean: 0.143/0.522 secs] >> 56752.766: [GC[YG occupancy: 77423 K (149120 K)]56752.766: >> [Rescan (parallel) , 0.0065730 secs]56752.773: [weak refs >> processing, 0.0001983 secs] [1 CMS-remark: 707208K(1402496K)] >> 784631K(1551616K), 0.0068908 secs] >> 56752.773: [CMS-concurrent-sweep-start] >> 56753.209: [CMS-concurrent-sweep: 0.436/0.436 secs] >> 56753.209: [CMS-concurrent-reset-start] >> 56753.219: [CMS-concurrent-reset: 0.010/0.010 secs] >> >> >> We only observe this behavior when a minor GC occurs during >> the Concurrent Mark (which is rare). Our app has reported >> pauses up to 1.2 seconds ... which is generally the time it >> takes to perform a Concurrent Mark. >> >> >> Any insight/help that you could provide would be much >> appreciated. >> >> Thanks >> >> >> _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Paul.Hohensee at Sun.COM Mon Sep 28 16:39:38 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 28 Sep 2009 19:39:38 -0400 Subject: unexplained CMS pauses In-Reply-To: <4AC148B6.7010608@Sun.COM> References: <4AC0EEAE.5010705@Sun.COM> <4AC145AE.30804@sun.com> <4AC148B6.7010608@Sun.COM> Message-ID: <4AC1493A.2030004@sun.com> Ouch. Missed that. Paul Y.S.Ramakrishna at Sun.COM wrote: > Hi Paul, that would be 100 us + minor gc time (=30 ms) = 30.1 ms. > It does not explain the 10- to 40-fold increase in txn times observed > here (of 300 ms - 1200 ms). > > -- ramki > > On 09/28/09 16:24, Paul Hohensee wrote: >> Might have nothing to do with concurrent mark running, rather with >> minor collections >> happening during a java->native call. >> >> Minor collections are stop-the-world, and if one occurs during a >> java->native call, the >> java thread making the call to native will block on return from the >> call to native until >> the minor collection is over. If the outliers are outliers in the >> time it takes to execute >> the native call, and the minor gc duration and timing are exactly >> right, you could end >> up spending most of the minor gc time blocked. Pause time would then >> be 100ms >> + minor gc time. >> >> Paul >> >> Shane Cox wrote: >>> Ramki, >>> We're running Solaris 10 on 8-core Intel Xeon's. 1 Java instance >>> per box. JRE 1.6, update 14. 64-bit JVM. >>> >>> Our app is making JNI calls. Each call requires approximately the >>> same amount of work (so we expect them to perform similarly). >>> Internally, we measure how long it takes to perform these calls. >>> +99% of these calls complete in less than 100 micros. However, we >>> have outliers in the 300-1200ms range. After some research, we have >>> found that these extreme outliers coincide with the Concurrent Mark >>> phase of CMS (based on timestamps), and ONLY if there is a minor GC >>> during that phase. >>> >>> In a given day, our app will execute CMS collections 500-1000 >>> times. Of these, less than 10 will have a minor collection execute >>> during the Concurrent Mark. For each of these, our app reports a >>> large pause in the 300-1200ms range. In fact, all of the large >>> pauses reported by our app correlate with a minor GC during a >>> Concurrent Mark, without exception. >>> >>> Thanks >>> >>> On Mon, Sep 28, 2009 at 1:13 PM, >> > wrote: >>> >>> What platform are you on (#cpu's etc.) >>> and when you say "app reports a pause of 300 ms" >>> is it that the odd transaction sees a latency >>> of 300 ms (coincident with concurrent mark), >>> whereas most transactions complete much more >>> quickly? >>> >>> I am trying to first understand how you determine >>> that the application is seeing "long pauses" >>> when a minor gc occurs during concurrent mark. >>> >>> PS: for example, if two gc pauses (say a scavenge of 30 ms >>> and an initial mark of 13 ms occur in quick succession, >>> your application might notice a pause of 43 ms, etc.) >>> >>> -- ramki >>> >>> >>> On 09/28/09 10:07, Shane Cox wrote: >>> >>> Our application is reporting long pauses when a minor GC >>> occurs during the Concurrent Mark phase of CMS. The output >>> below is a specific example. All of the GC pauses are less >>> than 30ms (initial mark, remark, minor GC). However, our app >>> reported a 300ms pause. >>> >>> 56750.934: [GC [1 CMS-initial-mark: 702464K(1402496K)] >>> 719045K(1551616K), 0.0131859 secs] >>> 56750.947: [CMS-concurrent-mark-start] >>> 56752.133: [GC 56752.133: [ParNew: 144393K->12122K(149120K), >>> 0.0237615 secs] 846857K->719330K(1551616K), 0.0239988 secs] >>> 56752.162: [CMS-concurrent-mark: 1.188/1.215 secs] >>> 56752.162: [CMS-concurrent-preclean-start] >>> 56752.243: [CMS-concurrent-preclean: 0.070/0.081 secs] >>> 56752.243: [CMS-concurrent-abortable-preclean-start] >>> 56752.765: [CMS-concurrent-abortable-preclean: 0.143/0.522 >>> secs] >>> 56752.766: [GC[YG occupancy: 77423 K (149120 K)]56752.766: >>> [Rescan (parallel) , 0.0065730 secs]56752.773: [weak refs >>> processing, 0.0001983 secs] [1 CMS-remark: 707208K(1402496K)] >>> 784631K(1551616K), 0.0068908 secs] >>> 56752.773: [CMS-concurrent-sweep-start] >>> 56753.209: [CMS-concurrent-sweep: 0.436/0.436 secs] >>> 56753.209: [CMS-concurrent-reset-start] >>> 56753.219: [CMS-concurrent-reset: 0.010/0.010 secs] >>> >>> >>> We only observe this behavior when a minor GC occurs during >>> the Concurrent Mark (which is rare). Our app has reported >>> pauses up to 1.2 seconds ... which is generally the time it >>> takes to perform a Concurrent Mark. >>> >>> >>> Any insight/help that you could provide would be much >>> appreciated. >>> >>> Thanks >>> >>> >>> > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use