From y.s.ramakrishna at sun.com Thu Apr 2 21:12:00 2009 From: y.s.ramakrishna at sun.com (y.s.ramakrishna at sun.com) Date: Fri, 03 Apr 2009 04:12:00 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6824570: ParNew: Fix memory leak introduced in 6819891 Message-ID: <20090403041206.3888DE163@hg.openjdk.java.net> Changeset: becb17ad5e51 Author: ysr Date: 2009-04-02 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/becb17ad5e51 6824570: ParNew: Fix memory leak introduced in 6819891 Summary: Allocate worker-local overflow stacks, introduced in 6819891, along with ParNewGeneration, rather than with the per-scavenge ParScanThreadState. Reviewed-by: jmasa ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From john.coomes at sun.com Fri Apr 3 01:03:30 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 08:03:30 +0000 Subject: hg: jdk7/hotspot-gc: 2 new changesets Message-ID: <20090403080330.5E53BE202@hg.openjdk.java.net> Changeset: c235f4a8559d Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/c235f4a8559d Added tag jdk7-b52 for changeset 4264c2fe6649 ! .hgtags Changeset: 2ef382b1bbd5 Author: xdono Date: 2009-04-02 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/2ef382b1bbd5 Added tag jdk7-b53 for changeset c235f4a8559d ! .hgtags From john.coomes at sun.com Fri Apr 3 01:07:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 08:07:36 +0000 Subject: hg: jdk7/hotspot-gc/corba: 5 new changesets Message-ID: <20090403080741.8632EE207@hg.openjdk.java.net> Changeset: 126389a38e7d Author: tbell Date: 2009-03-23 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/126389a38e7d 6695776: corba jscheme jar files in repository could be built from source Summary: Forward port of changes from the 6-open train. Reviewed-by: darcy, ohair, tbell Contributed-by: Andrew John Hughes ! make/com/sun/corba/se/sources/Makefile ! make/sun/rmi/corbalogsources/Makefile ! make/tools/Makefile + make/tools/logutil/Makefile ! src/share/classes/com/sun/tools/corba/se/logutil/IndentingPrintWriter.java + src/share/classes/com/sun/tools/corba/se/logutil/Input.java + src/share/classes/com/sun/tools/corba/se/logutil/InputCode.java + src/share/classes/com/sun/tools/corba/se/logutil/InputException.java + src/share/classes/com/sun/tools/corba/se/logutil/MC.java - src/share/classes/com/sun/tools/corba/se/logutil/lib/jscheme.jar - src/share/classes/com/sun/tools/corba/se/logutil/lib/jschemelogutil.jar - src/share/classes/com/sun/tools/corba/se/logutil/scripts/mc - src/share/classes/com/sun/tools/corba/se/logutil/scripts/mc.scm - src/share/classes/com/sun/tools/corba/se/logutil/scripts/run Changeset: 61116c9789b9 Author: tbell Date: 2009-03-23 17:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/61116c9789b9 Merge Changeset: 2e02b4137dad Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/2e02b4137dad Added tag jdk7-b52 for changeset bec82237d694 ! .hgtags Changeset: 3c4d73194f6f Author: xdono Date: 2009-03-31 08:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/3c4d73194f6f Merge - src/share/classes/com/sun/tools/corba/se/logutil/lib/jscheme.jar - src/share/classes/com/sun/tools/corba/se/logutil/lib/jschemelogutil.jar - src/share/classes/com/sun/tools/corba/se/logutil/scripts/mc - src/share/classes/com/sun/tools/corba/se/logutil/scripts/mc.scm - src/share/classes/com/sun/tools/corba/se/logutil/scripts/run Changeset: 8130ac858d67 Author: xdono Date: 2009-04-02 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/8130ac858d67 Added tag jdk7-b53 for changeset 3c4d73194f6f ! .hgtags From john.coomes at sun.com Fri Apr 3 01:18:01 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 08:18:01 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: 4 new changesets Message-ID: <20090403081808.E0E03E20C@hg.openjdk.java.net> Changeset: 30e3f9614f07 Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/30e3f9614f07 Added tag jdk7-b52 for changeset 69ad87dc25cb ! .hgtags Changeset: 996284fd4afe Author: ohair Date: 2009-03-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/996284fd4afe 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config Changeset: e8837366d3fd Author: xdono Date: 2009-04-01 08:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/e8837366d3fd Merge Changeset: 946a9f0c4932 Author: xdono Date: 2009-04-02 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/946a9f0c4932 Added tag jdk7-b53 for changeset e8837366d3fd ! .hgtags From john.coomes at sun.com Fri Apr 3 01:21:59 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 08:21:59 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: 4 new changesets Message-ID: <20090403082206.0EACBE211@hg.openjdk.java.net> Changeset: 2c10f0cbb34e Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/2c10f0cbb34e Added tag jdk7-b52 for changeset e646890d18b7 ! .hgtags Changeset: 0814199b8ee7 Author: ohair Date: 2009-03-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/0814199b8ee7 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config Changeset: b250218eb2e5 Author: xdono Date: 2009-04-01 08:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/b250218eb2e5 Merge Changeset: 50ea00dc5f14 Author: xdono Date: 2009-04-02 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/50ea00dc5f14 Added tag jdk7-b53 for changeset b250218eb2e5 ! .hgtags From john.coomes at sun.com Fri Apr 3 01:26:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 08:26:04 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 29 new changesets Message-ID: <20090403083416.4E45AE21A@hg.openjdk.java.net> Changeset: e1064300e0f6 Author: mchung Date: 2009-03-12 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e1064300e0f6 6810254: Lazily instantiate the shared secret access objects Summary: Register the shutdown hooks only when needed and remove JavaIODeleteOnExitAccess Reviewed-by: alanb ! make/java/java/FILES_java.gmk ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/io/File.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Shutdown.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaIOAccess.java - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/SharedSecrets.java Changeset: fdb1567ea28c Author: mchung Date: 2009-03-12 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fdb1567ea28c 6813240: Remove dead code in sun.misc.FormattedFloatingDecimal class Summary: Remove unused methods from FormattedFloatingDecimal that were originally copied from FloatingDecimal Reviewed-by: darcy ! src/share/classes/sun/misc/FormattedFloatingDecimal.java Changeset: 9d5cce463fa0 Author: weijun Date: 2009-03-13 09:20 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9d5cce463fa0 6815182: GSSAPI/SPNEGO does not work with server using MIT Kerberos library Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/spnego/NegTokenInit.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test/sun/security/krb5/auto/SpnegoReqFlags.java Changeset: ef3eba839fb7 Author: weijun Date: 2009-03-13 09:21 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ef3eba839fb7 6550221: jaas, jgss and smartcardio javadoc files do not contain Copyrights Reviewed-by: ohair ! make/docs/Makefile Changeset: f381e737916d Author: xuelei Date: 2009-03-13 12:59 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f381e737916d 6798714: OCSPResponse class has to check the validity of signing certificate for OCSP response Summary: checking validity and ocsp-nocheck extension. Reviewed-by: mullan, vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java + src/share/classes/sun/security/x509/OCSPNoCheckExtension.java ! src/share/classes/sun/security/x509/OIDMap.java ! src/share/classes/sun/security/x509/PKIXExtensions.java Changeset: c2ca4a97ba86 Author: tbell Date: 2009-03-13 15:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c2ca4a97ba86 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: 181472dbbebb Author: xuelei Date: 2009-03-17 11:54 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/181472dbbebb 6383095: CRL revoked certificate failures masked by OCSP failures Summary: remove the mask if certificate revoked Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java + test/java/security/cert/CertPathValidator/OCSP/FailoverToCRL.java Changeset: 171dc1779708 Author: tbell Date: 2009-03-17 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/171dc1779708 6814587: Legal notice repair needed in jdk/src/share/classes/java/nio 6814590: Legal notice repair needed in jdk/test/java/awt/Frame/FrameSize/TestFrameSize.java 6814591: Legal notice repair needed in jdk/test/javax/script/Test3.java Reviewed-by: alanb, xdono ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! test/java/awt/Frame/FrameSize/TestFrameSize.java ! test/javax/script/Test3.java Changeset: fa87de6b1ac3 Author: dfuchs Date: 2009-03-12 15:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fa87de6b1ac3 6661448: Make the SNMP agent optional when OPENJDK=true and IMPORT_BINARY_PLUGS=false Reviewed-by: mchung, ohair ! make/com/sun/jmx/Makefile ! make/java/management/Makefile ! make/javax/management/Makefile ! make/sun/management/Makefile ! src/share/classes/sun/management/Agent.java ! test/com/sun/jmx/snmp/SnmpOidHashCode.java ! test/com/sun/jmx/snmp/TimeTicksWrapping.java Changeset: e90ce2ac06a8 Author: dfuchs Date: 2009-03-13 14:25 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e90ce2ac06a8 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: ef27484bbd7f Author: dfuchs Date: 2009-03-18 18:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ef27484bbd7f Merge Changeset: 392cd358db5d Author: mchung Date: 2009-03-18 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/392cd358db5d 6817246: Redundant call to set InetAddressCachePolicy to FOREVER if not set during initialization Summary: Remove InetAddressCachePolicy.setIfNotSet call from System.setSecurityManager0 Reviewed-by: alanb, jccollet ! src/share/classes/java/lang/System.java Changeset: 87acd36bd847 Author: weijun Date: 2009-03-19 11:17 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/87acd36bd847 6819272: keytool -importcert should read the whole input Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/importreadall.sh Changeset: 3b6d7e15ccd9 Author: sherman Date: 2009-03-20 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3b6d7e15ccd9 6817475: named-capturing group name started with digit causes PSE exception Summary: Need accept the digit as the first char of the group name Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: c6b37e92e387 Author: sherman Date: 2009-03-20 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c6b37e92e387 Merge ! src/share/classes/java/util/regex/Pattern.java - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: cc8ffb0fc1a4 Author: tbell Date: 2009-03-21 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cc8ffb0fc1a4 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: 74fe20f0e49b Author: weijun Date: 2009-03-23 17:05 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/74fe20f0e49b 6820606: keytool can generate serialno more randomly Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java Changeset: 4faf788c4949 Author: sherman Date: 2009-03-23 09:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4faf788c4949 6636323: Optimize handling of builtin charsets 6636319: Encoders should implement isLegalReplacement(byte[] repl) Summary: optimized new String(byte[], cs/csn) and String.getBytes(cs/csn) for speed and memory consumption in singlebyte case. Reviewed-by: alanb ! make/java/nio/FILES_java.gmk ! src/share/classes/java/lang/StringCoding.java + src/share/classes/sun/nio/cs/ArrayDecoder.java + src/share/classes/sun/nio/cs/ArrayEncoder.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/US_ASCII.java ! test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/StrCodingBenchmark.java + test/sun/nio/cs/TestStringCoding.java Changeset: b9cc5da6c516 Author: sherman Date: 2009-03-23 09:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b9cc5da6c516 Merge Changeset: 13cd6eb34cfa Author: tbell Date: 2009-03-23 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/13cd6eb34cfa 6695776: corba jscheme jar files in repository could be built from source Summary: Forward port of changes from the 6-open train. Reviewed-by: darcy, ohair, tbell Contributed-by: Andrew John Hughes ! THIRD_PARTY_README Changeset: 8306f3df15ff Author: tbell Date: 2009-03-23 17:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8306f3df15ff Merge - make/common/shared/Compiler.gmk Changeset: 3501cc282cd2 Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3501cc282cd2 Added tag jdk7-b52 for changeset bcbeadb4a5d7 ! .hgtags Changeset: 1bbbd1bf9be3 Author: xdono Date: 2009-03-31 08:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1bbbd1bf9be3 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: 90873391a0e0 Author: ohair Date: 2009-03-26 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/90873391a0e0 6822374: Windows: detect X64 when PROCESSOR_IDENTIFIER contains EM64T or Intel64 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell ! make/common/shared/Platform.gmk ! make/jdk_generic_profile.sh - make/jprt.config Changeset: 964cc8eb3232 Author: tbell Date: 2009-03-31 15:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/964cc8eb3232 6819847: build is broken for OpenJDK with plugs Reviewed-by: jjg, robilad, ohair ! make/Makefile ! make/common/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/java/redist/Makefile Changeset: ecb7723aaa7c Author: tbell Date: 2009-04-01 04:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ecb7723aaa7c 6824595: OpenJDK fix breaks product build for jdk7 Reviewed-by: xdono, ohair ! make/Makefile Changeset: deced414c8e4 Author: xdono Date: 2009-04-01 08:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/deced414c8e4 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: a2033addca67 Author: ohair Date: 2009-04-01 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a2033addca67 6825175: Remove or disable sanity check on binary plugs Reviewed-by: xdono ! make/common/shared/Sanity.gmk Changeset: 8536cdffa32e Author: xdono Date: 2009-04-02 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8536cdffa32e Added tag jdk7-b53 for changeset a2033addca67 ! .hgtags From john.coomes at sun.com Fri Apr 3 01:43:30 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 08:43:30 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 9 new changesets Message-ID: <20090403084346.33EF1E245@hg.openjdk.java.net> Changeset: 889ec3ddc91b Author: tbell Date: 2009-03-17 11:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/889ec3ddc91b 6814592: Legal notice repair needed in langtools/test/tools/javap/T4884240.java Reviewed-by: jjg ! test/tools/javap/T4884240.java Changeset: edd944553131 Author: bpatel Date: 2009-03-19 19:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/edd944553131 6786688: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Table must have captions and headers Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java + test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testHtmlTableTags/pkg1/C1.java + test/com/sun/javadoc/testHtmlTableTags/pkg1/I1.java + test/com/sun/javadoc/testHtmlTableTags/pkg1/package-info.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/C2.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/C3.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/C4.java + test/com/sun/javadoc/testHtmlTableTags/pkg2/package-info.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java Changeset: b000f7c728ae Author: bpatel Date: 2009-03-20 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/b000f7c728ae 6820360: Fix for definition list tags nesting adds an extra list tag for package summary page. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/package-info.java Changeset: 3bf905cb80e7 Author: tbell Date: 2009-03-21 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/3bf905cb80e7 Merge Changeset: 1ec9ff434ce2 Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/1ec9ff434ce2 Added tag jdk7-b52 for changeset 29329051d483 ! .hgtags Changeset: 72c2df1a2b5a Author: xdono Date: 2009-03-31 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/72c2df1a2b5a Merge Changeset: 39c674c60a36 Author: ohair Date: 2009-03-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/39c674c60a36 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config Changeset: dbdeb4a7581b Author: xdono Date: 2009-04-01 08:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/dbdeb4a7581b Merge Changeset: 197a7f881937 Author: xdono Date: 2009-04-02 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/197a7f881937 Added tag jdk7-b53 for changeset dbdeb4a7581b ! .hgtags From john.coomes at sun.com Fri Apr 3 03:09:23 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 03 Apr 2009 10:09:23 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6810474: par compact - crash in summary_phase with very full heap Message-ID: <20090403100929.3C891E280@hg.openjdk.java.net> Changeset: f18338cf04b0 Author: jcoomes Date: 2009-03-03 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f18338cf04b0 6810474: par compact - crash in summary_phase with very full heap Reviewed-by: tonyp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp From andrey.petrusenko at sun.com Mon Apr 6 07:38:38 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 06 Apr 2009 14:38:38 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 38 new changesets Message-ID: <20090406144135.E9AA7E475@hg.openjdk.java.net> Changeset: 54782a4cd321 Author: poonam Date: 2009-03-15 18:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/54782a4cd321 6812971: SA: re-attaching to process fails Summary: After attaching, de-attaching SA from a process, the second time attach() call fails. This happens because in VM.initialize(), Universe does not get re-initialized before it is accessed. Reviewed-by: swamyv ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java Changeset: 8ce995316d10 Author: acorn Date: 2009-03-16 08:50 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8ce995316d10 Merge Changeset: 4aaa9f5e02a8 Author: acorn Date: 2009-03-18 17:20 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4aaa9f5e02a8 4766230: Hotspot vtable inconsistencies cause core dumps. 6579515. 6582242. Reviewed-by: kamg, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp Changeset: e55bcaf3a6a1 Author: acorn Date: 2009-03-20 11:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e55bcaf3a6a1 6819853: VM does not detect JDK which supports parallel class loaders Reviewed-by: coleenp, pbk, xlu, alanb ! src/share/vm/classfile/vmSymbols.hpp Changeset: c664a0794f85 Author: coleenp Date: 2009-03-20 22:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c664a0794f85 6805748: Assertion "don't reset to 0 -- could be mistaken for never-executed" in CompilationPolicy Summary: Resetting the invocation counter for a method invocation event was setting count to zero for CompileThreshold=1, making it look like a never executed method. Reviewed-by: phh, kamg, acorn, never ! src/share/vm/interpreter/invocationCounter.cpp Changeset: 60bfce711da4 Author: acorn Date: 2009-03-23 10:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/60bfce711da4 Merge ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/classfile/vmSymbols.hpp Changeset: 6bdd6923ba16 Author: coleenp Date: 2009-03-25 14:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6bdd6923ba16 6541756: Reduce executable C-heap Summary: Add executable parameters to reserve_memory and commit_memory to reduce executable memory to only the Code Heap. Reviewed-by: xlu, kvn, acorn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 715dceaa89b7 Author: acorn Date: 2009-03-25 13:09 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/715dceaa89b7 6603316: Improve instrumentation for classes loaded at startup Reviewed-by: xlu, mchung ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp Changeset: fe62b51b93f4 Author: acorn Date: 2009-03-26 16:00 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fe62b51b93f4 Merge Changeset: 520d43965b1f Author: ikrylov Date: 2009-03-27 01:35 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/520d43965b1f 6812297: update project creation for Visual Studio 2005-2008 Summary: Add 2 news classes to create VC8 and VC9 projects Reviewed-by: apetrusenko, xlu ! make/windows/build_vm_def.sh ! make/windows/create.bat ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/makedeps.make ! make/windows/makefiles/rules.make ! src/share/tools/MakeDeps/WinGammaPlatformVC7.java + src/share/tools/MakeDeps/WinGammaPlatformVC8.java + src/share/tools/MakeDeps/WinGammaPlatformVC9.java ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 0aeec7d15d30 Author: acorn Date: 2009-03-27 14:35 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/0aeec7d15d30 Merge Changeset: 1b1e8f1a4fe8 Author: xdono Date: 2009-03-19 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1b1e8f1a4fe8 Added tag jdk7-b51 for changeset 2581d90c6c9b ! .hgtags Changeset: 00bcc4b01dde Author: trims Date: 2009-03-27 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/00bcc4b01dde Merge Changeset: 9ab385cb0c42 Author: trims Date: 2009-03-27 16:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9ab385cb0c42 6823377: Bump HS15 build number to 04 Summary: Update the HS15 Build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c89f86385056 Author: jrose Date: 2009-03-20 23:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c89f86385056 6814659: separable cleanups and subroutines for 6655638 Summary: preparatory but separable changes for method handles Reviewed-by: kvn, never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: ebebd376f657 Author: never Date: 2009-03-23 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ebebd376f657 6805522: Server VM fails with assertion (block1->start() != block2->start(),"successors have unique bcis") Reviewed-by: kvn ! src/share/vm/ci/ciTypeFlow.cpp Changeset: 78af5ae8e731 Author: cfang Date: 2009-03-24 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/78af5ae8e731 6636138: UseSuperWord enabled failure Summary: Fixed SuperWord scheduling of memory operations. Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/6636138/Test1.java + test/compiler/6636138/Test2.java Changeset: 90a66aa50514 Author: never Date: 2009-03-24 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/90a66aa50514 6820510: assertion failure with unloaded class in subnode.cpp Reviewed-by: kvn ! src/share/vm/opto/subnode.cpp Changeset: eca19a8425b5 Author: phh Date: 2009-03-24 21:56 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/eca19a8425b5 6810653: Change String cache class used by Hotspot from String to StringValue Summary: Change create_vm() to load and initialize StringValue rather than String. Reviewed-by: kvn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: c7bbabdcadfb Author: phh Date: 2009-03-24 19:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c7bbabdcadfb Merge Changeset: d0994e5bebce Author: never Date: 2009-03-26 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d0994e5bebce 6822204: volatile fences should prefer lock:addl to actual mfence instructions Reviewed-by: kvn, phh ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp Changeset: afd8dfb5c2a6 Author: never Date: 2009-03-26 14:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/afd8dfb5c2a6 Merge Changeset: fbc12e71c476 Author: kvn Date: 2009-03-26 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fbc12e71c476 6810845: Performance regression in mpegaudio on x64 Summary: Used the outer loop frequency in frequencies checks in RA. Reviewed-by: never, twisti ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/machnode.cpp Changeset: 4948e7dd28dc Author: never Date: 2009-03-27 14:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4948e7dd28dc 6822333: _call_stub_compiled_return address handling in SA is broken causing jstack to hang occasionally Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/StubRoutines.java Changeset: f6da6f0174ac Author: kvn Date: 2009-03-30 18:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f6da6f0174ac 6821700: tune VM flags for peak performance Summary: Tune C2 flags default values for performance. Reviewed-by: never, phh, iveresov, jmasa, ysr ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/globals.hpp Changeset: d3676b4cb78c Author: kvn Date: 2009-03-31 10:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d3676b4cb78c Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/prims/jvm.cpp Changeset: a80d48f6fde1 Author: apetrusenko Date: 2009-04-02 05:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a80d48f6fde1 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/runtime/globals.hpp Changeset: fbde8ec322d0 Author: cfang Date: 2009-03-31 14:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fbde8ec322d0 6761600: Use sse 4.2 in intrinsics Summary: Use SSE 4.2 in intrinsics for String.{compareTo/equals/indexOf} and Arrays.equals. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 69aefafe69c1 Author: never Date: 2009-03-31 15:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/69aefafe69c1 6824463: deopt blob is testing wrong register on 64-bit x86 Reviewed-by: jrose, phh, kvn ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 90e3155a713d Author: never Date: 2009-03-31 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/90e3155a713d Merge Changeset: 7230de7c4610 Author: never Date: 2009-04-01 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/7230de7c4610 6823454: Oop-typed loadP yields invalid pointer (0x1) on SPECjbb2005 at OSRed method entry Reviewed-by: kvn, jrose ! src/share/vm/opto/parse1.cpp Changeset: 4e35bfab60a5 Author: never Date: 2009-04-02 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4e35bfab60a5 Merge ! src/share/vm/runtime/globals.hpp Changeset: f30ba3b36599 Author: poonam Date: 2009-03-27 10:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f30ba3b36599 6822407: heapOopSize lookup is incorrect in Serviceability Agent. Summary: heapOopSize symbol should be declared as constant in vmStructs and should not be looked up in readVMIntConstants(). Reviewed-by: never, swamyv, coleenp ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: d142f1feeed5 Author: acorn Date: 2009-03-29 18:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d142f1feeed5 Merge Changeset: 956304450e80 Author: phh Date: 2009-04-01 16:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/956304450e80 6819213: revive sun.boot.library.path Summary: Support multiplex and mutable sun.boot.library.path Reviewed-by: acorn, dcubed, xlu ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/hpi.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + test/runtime/6819213/TestBootNativeLibraryPath.java Changeset: 23276f80d930 Author: acorn Date: 2009-04-02 14:26 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/23276f80d930 6825642: nsk sajdi tests fail with NullPointerException Reviewed-by: xlu, coleenp, kamg, swamyv ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 2c1dbb844832 Author: acorn Date: 2009-04-02 18:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2c1dbb844832 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 922aedc96ef5 Author: ysr Date: 2009-04-03 15:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/922aedc96ef5 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From Y.S.Ramakrishna at Sun.COM Mon Apr 6 11:27:24 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 06 Apr 2009 11:27:24 -0700 Subject: CMS changes from 6u4 to 6u11 ? In-Reply-To: <200904061407.20880.adamh@basis.com> References: <200904061407.20880.adamh@basis.com> Message-ID: <49DA498C.1030304@Sun.COM> If you run a 32-bit JVM on a 64-bit OS you do not need to increase the heap size, since the native pointers used by your JVM are still just 32-bit. (I am assuming from yr email below that you are still running a 32-bit JVM process on your 64-bit server.) In any case, that should not cause any such issues, nor I believe should the upgrade from 6u4 to 6u11. Two questions to investigate: (1) the effect of virtualization: (a) are there other guests sharing those 4 processors with this guest? (b) do you see sluggishness in general or only when the concurrent collector runs? (2) could you send the logs from both cases? (In the interests of not cluttering up everyone's mailboxes, send them to me directly rather than to the list, unless others have also expressed an interest.) As always, of course, remember that although there are Sun employees on this list, this is a community list and not an official Sun support channel, even when Sun employees respond to your questions. For official Sun support channels, please turn to sun.com/services -- ramki On 04/06/09 11:07, Adam Hawthorne wrote: > I have a customer with whom I worked a long time between 6u1 and 6u4, when Sun fixed the bug about very long pause times on Linux due to stopping all the application threads. That fix resolved the issues he saw where he would see the load climb up to ~80-100 and then everything would begin running again. > > The customer recently made four significant system changes: > > 1. New version of our product > 2. Java upgrade from 6u4 to 6u11 > 3. 32-bit -> 64-bit machine > 4. VMWare virtualization > > The previous machine was a 4-way Intel on 32-bit RedHat Advance Server 4/Linux 2.6.9. The new machine is an 8-way Xeon E4540 on Suse 10 SP2 64-bit/2.6.16. The VMWare instance allocates 4 processors and 8GB of RAM. Since he moved to 64-bit, I suggested he increase his -Xmx and -Xms by about 30%. > > This is his old Java commandline: > > -Xmx2048m -Xms900m -XX\:NewRatio\=4 -XX\:MaxNewSize\=200m -XX\:+ExplicitGCInvokesConcurrent -XX\:+UseConcMarkSweepGC -XX\:+UseParNewGC -XX\:+CMSParallelRemarkEnabled -XX\:CMSInitiatingOccupancyFraction\=50 -XX\:+PrintGCDetails -XX\:+PrintGCTimeStamps -server -verbose\:gc -Xloggc\:logs/gc.txt -XX\:CompileCommandFile\=cfg/.hotspot_compiler -Dnetworkaddress.cache.ttl\=10 -Dsun.net.inetaddr.ttl\=10 -Djava.awt.headless\=true -XX\:+PrintGCApplicationStoppedTime > > I believe this upgrade occurred on Friday, 4/3. This morning, 4/6, he complained of sluggishness and high load again. I looked at his logs, and in the first hour, I saw a 29-second remark. > > He's rolled back to the previous version of our product to eliminate that variable as a source of confusion, but such a long remark was suspicious to me. I can send a log to anyone who wants to look. I may have another log from this most recent restart as well, as he's just informed me it's beginning to show some similar behavior. > > Thanks, > > Adam > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Apr 6 17:04:50 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 06 Apr 2009 17:04:50 -0700 Subject: Tracking size of the object that caused the collection In-Reply-To: References: Message-ID: <49DA98A2.90307@Sun.COM> Unfortunately, there isn't such a flag at the moment, although it would be very little work to add one. You can surmise that a GC is occuring for a large object allocation request based on how much of Eden is filled when the GC occurs, and whether the old generation growth was abnormally large during that collection. But these are of course approximate. -- ramki On 04/06/09 16:49, Alex Aisinzon wrote: > Hi all > > > > We have historically seen performance degradation when large Java > Objects were allocated. > > We came to this conclusion after reviewing some logs provided with > another JVM that trace the size of the object that triggered the collection. > > Is there a flag that can be set to allow tracing the size of the object > whose allocation triggered the garbage collection? > > Our current target would be Sun JDK 1.5. > > > > Thanks in advance > > > > Alex Aisinzon > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Peter.Kessler at Sun.COM Mon Apr 6 17:43:06 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 06 Apr 2009 17:43:06 -0700 Subject: Tracking size of the object that caused the collection In-Reply-To: References: Message-ID: <49DAA19A.5060905@Sun.COM> What Ramki said. You can use -XX:+PrintHeapAtGC to see the remaining number of bytes in the eden space before each collection. Part of Ramki's approximation is that the eden is allocated in thread-local allocation buffers, so the eden may look like it is full (of TLABs) when an allocation from a TLAB fails. You can see the distribution of the sizes of the objects in the heap at any given time with "jmap -histo". That will show you the number of instances of each class and the total number of bytes occupied by those instances. For objects with fixed sizes (e.g., not arrays), you can use those numbers to figure out the size of an instance of each class. Then you can figure out your allocation distribution, and the probability that an allocation of any given class will cause a collection. It could also be that your objects are so large that they don't fit in a TLAB (though TLAB's grow and shrink as needed, but only within limits), in which case you'll be doing slow-path allocation for your large objects. That grabs a lock, but it's not a highly-contended lock, and it shouldn't be noticeably slower to allocate one large object than many small objects that occupy the same amount of memory. Large objects take longer to initialize than small objects, but again, not longer than initializing many small objects in the same amount of memory. It could be that your objects are large enough to be allocated directly in the old generation. If those objects are short-lived, then you will be causing more old generation collections, which are not designed for short-lived objects and so will have more overhead than if the objects were allocated and collected from the young generation. But you didn't actually say what problem you are trying to solve. This sounds like a strange lamppost to be looking under. Collections are triggered (usually) by generations being too full to satisfy an allocation request. Then the cost of the collection should be thought of as amortized over all the allocations that filled the generation. Of course larger objects have a greater chance of being the ones that don't fit when a generation is getting full. But looking at just the object that pushes you over the edge is a biased sampling. A large object that causes a collection is no more "at fault" than all the little objects that filled up the generation to the point where there's no room for the large object. If your allocation pattern were different, such that the large object were allocated first and the little objects were allocated later, then you might never see the large object as "causing" a collection. (This temporal argument is dubious, since allocation is a continuous process: you would be hard-pressed to order your allocatio ns such that your large objects were allocated just after a collection. But I hope you get the idea.) ... peter Alex Aisinzon wrote: > Hi all > > > > We have historically seen performance degradation when large Java > Objects were allocated. > > We came to this conclusion after reviewing some logs provided with > another JVM that trace the size of the object that triggered the collection. > > Is there a flag that can be set to allow tracing the size of the object > whose allocation triggered the garbage collection? > > Our current target would be Sun JDK 1.5. > > > > Thanks in advance > > > > Alex Aisinzon > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From John.Coomes at sun.com Tue Apr 7 18:09:13 2009 From: John.Coomes at sun.com (John Coomes) Date: Tue, 7 Apr 2009 18:09:13 -0700 Subject: review request (s) - 6821693 64-bit TaskQueue capacity still too small Message-ID: <18907.63801.791072.880801@sun.com> http://cr.openjdk.java.net/~jcoomes/6821693-taskqueue64/ Just one file. Testing is still in progress, but the initial results are clean. -John From Igor.Veresov at Sun.COM Wed Apr 8 13:59:22 2009 From: Igor.Veresov at Sun.COM (Igor Veresov) Date: Wed, 08 Apr 2009 13:59:22 -0700 Subject: Request for review(XL): 6484957, 6826318 Message-ID: <49DD102A.8060302@sun.com> Fixed 6484957 G1: parallel concurrent refinement Fixed 6826318 G1: remove traversal-based refinement code Removed traversal-based refinement code as it's no longer used. Made the concurrent refinement (queue-based) parallel. Webrev: http://cr.openjdk.java.net/~iveresov/6484957/webrev.00 Testing: specjbb2005, jprt From john.coomes at sun.com Thu Apr 9 22:16:54 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 10 Apr 2009 05:16:54 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b54 for changeset 2ef382b1bbd5 Message-ID: <20090410051655.049E9E7FD@hg.openjdk.java.net> Changeset: aea0ace7a1e4 Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/aea0ace7a1e4 Added tag jdk7-b54 for changeset 2ef382b1bbd5 ! .hgtags From john.coomes at sun.com Thu Apr 9 22:20:17 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 10 Apr 2009 05:20:17 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b54 for changeset 8130ac858d67 Message-ID: <20090410052018.C55CCE802@hg.openjdk.java.net> Changeset: 7a869f16ba83 Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/7a869f16ba83 Added tag jdk7-b54 for changeset 8130ac858d67 ! .hgtags From john.coomes at sun.com Thu Apr 9 22:28:38 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 10 Apr 2009 05:28:38 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b54 for changeset 946a9f0c4932 Message-ID: <20090410052840.8C33BE80B@hg.openjdk.java.net> Changeset: 039945fba683 Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/039945fba683 Added tag jdk7-b54 for changeset 946a9f0c4932 ! .hgtags From john.coomes at sun.com Thu Apr 9 22:32:22 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 10 Apr 2009 05:32:22 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b54 for changeset 50ea00dc5f14 Message-ID: <20090410053225.24492E810@hg.openjdk.java.net> Changeset: e0eebd978b83 Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/e0eebd978b83 Added tag jdk7-b54 for changeset 50ea00dc5f14 ! .hgtags From john.coomes at sun.com Thu Apr 9 22:37:52 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 10 Apr 2009 05:37:52 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 42 new changesets Message-ID: <20090410054700.994CFE815@hg.openjdk.java.net> Changeset: 9d14b0582e1a Author: bae Date: 2008-12-12 17:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9d14b0582e1a 5106550: PNG writer merge standard metadata fails for TextEntry sans #IMPLIED attributes Reviewed-by: igor, prr Contributed-by: Martin von Gagern ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/MergeStdCommentTest.java Changeset: 11d333de082f Author: igor Date: 2008-12-17 22:00 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/11d333de082f 6761791: Crash in the FontManager code due to use of JNIEnv saved by another thread Reviewed-by: bae, prr ! src/share/native/sun/font/freetypeScaler.c Changeset: feee56c07a8a Author: prr Date: 2008-12-18 11:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/feee56c07a8a 6708137: Remove obsolete fontconfig.98.properties from JDK 7 Reviewed-by: jgodinez, naoto ! make/sun/awt/Makefile ! src/windows/classes/sun/awt/windows/WFontConfiguration.java - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties Changeset: f68864fe53d3 Author: prr Date: 2008-12-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f68864fe53d3 6728838: Native memory leak in StrikeCache.java Reviewed-by: bae, igor ! src/share/classes/sun/font/StrikeCache.java Changeset: 40ec164889bd Author: prr Date: 2008-12-24 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/40ec164889bd 6752638: java.awt.GraphicsEnvironment.preferLocaleFonts() throws NPE on Linux 6755034: Legal notice repair: jdk/src/solaris/classes/sun/font/FcFontConfiguration.java Reviewed-by: bae, igor ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java + test/java/awt/GraphicsEnvironment/PreferLocaleFonts.java Changeset: eaeaacda1c56 Author: prr Date: 2009-01-06 13:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/eaeaacda1c56 6785424: SecurityException locating physical fonts on Windows Terminal Server Reviewed-by: campbell, jgodinez ! src/share/classes/sun/font/FontManager.java + test/java/awt/FontClass/FontAccess.java Changeset: 91bc016862c4 Author: prr Date: 2009-01-12 16:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/91bc016862c4 6752622: java.awt.Font.getPeer throws "java.lang.InternalError: Not implemented" on Linux Reviewed-by: igor, yan ! src/solaris/classes/sun/awt/X11/XFontPeer.java ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: 80fb12052ae4 Author: bae Date: 2009-01-13 16:55 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/80fb12052ae4 5082756: Image I/O plug-ins set metadata boolean attributes to "true" or "false" Reviewed-by: igor, prr Contributed-by: Martin von Gagern ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFMetadata.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java + test/javax/imageio/metadata/BooleanAttributes.java ! test/javax/imageio/plugins/png/ITXtTest.java Changeset: 62d33a33f9e0 Author: bae Date: 2009-01-13 18:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/62d33a33f9e0 6782079: PNG: reading metadata may cause OOM on truncated images. Reviewed-by: igor, prr Contributed-by: Martin von Gagern ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/ItxtUtf8Test.java Changeset: 774083387e81 Author: bae Date: 2009-01-15 13:55 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/774083387e81 6788096: ImageIO SreamCloser causes memory leak in FX applets Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/stream/StreamCloser.java + test/javax/imageio/stream/StreamCloserLeak/run_test.sh + test/javax/imageio/stream/StreamCloserLeak/test/Main.java + test/javax/imageio/stream/StreamCloserLeak/testapp/Main.java Changeset: 828d4d5e7bf8 Author: bae Date: 2009-01-23 17:43 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/828d4d5e7bf8 6795544: GIFImageWriter does not write the subImage of BufferedImage to a file correctly. Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java + test/javax/imageio/plugins/gif/EncodeSubImageTest.java Changeset: 6d343a2795ca Author: bae Date: 2009-01-23 21:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6d343a2795ca 6793818: JpegImageReader is too greedy creating color profiles Reviewed-by: igor, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/sun/java2d/cmm/ProfileActivator.java ! src/share/classes/sun/java2d/cmm/ProfileDeferralMgr.java Changeset: 65cada5a8497 Author: jgodinez Date: 2009-01-28 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/65cada5a8497 6793344: BasicStroke's first element dash pattern is not a dash Reviewed-by: igor, flar Contributed-by: Red Hat ! src/share/classes/sun/java2d/pisces/Dasher.java + test/sun/pisces/DashStrokeTest.java Changeset: 36da64dc6545 Author: bae Date: 2009-01-29 13:19 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/36da64dc6545 6631559: Registration of ImageIO plugins should not cause loading of jpeg.dlli and cmm.dll Reviewed-by: igor, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java ! src/share/classes/javax/imageio/ImageTypeSpecifier.java Changeset: a7836e00ad6b Author: lana Date: 2009-01-29 18:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a7836e00ad6b Merge - src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: f0978a1137fe Author: bae Date: 2009-01-30 22:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f0978a1137fe 6791502: IIOException "Invalid icc profile" on jpeg after update from JDK5 to JDK6 Reviewed-by: igor, prr ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: e0a9038939ee Author: bae Date: 2009-02-04 14:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e0a9038939ee 6799583: LogManager shutdown hook may cause a memory leak. Reviewed-by: igor, swamyv ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/ClassLoaderLeakTest.java Changeset: b02162077f24 Author: bae Date: 2009-02-06 20:49 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b02162077f24 6800846: REGRESSION: Printing quality degraded with Java 6 compared to 5.0 Reviewed-by: igor, prr ! src/share/native/sun/awt/image/dither.c + test/sun/awt/image/DrawByteBinary.java Changeset: ff2afd0551c9 Author: jgodinez Date: 2009-02-24 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ff2afd0551c9 6750383: 2D_PrintingTiger\PrintDocOrientationTest fails, wrong orientated images are printed Reviewed-by: campbell, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 0c856354b669 Author: tdv Date: 2009-02-26 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0c856354b669 6791612: OGLBat tests are failed in jdk 7 b42 Reviewed-by: tdv Contributed-by: ceisserer ! make/sun/xawt/mapfile-vers Changeset: c32ec45b582d Author: lana Date: 2009-03-04 10:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c32ec45b582d Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! make/sun/awt/Makefile ! make/sun/xawt/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 8d5144dfc642 Author: jgodinez Date: 2009-03-05 10:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8d5144dfc642 6735296: Regression: Common print dialog does not show the correct page orientation Reviewed-by: tdv, prr ! src/share/classes/sun/print/ServiceDialog.java Changeset: 59696dfd5455 Author: prr Date: 2009-03-12 12:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/59696dfd5455 6727719: Performance of TextLayout.getBounds() Reviewed-by: jgodinez, dougfelt ! src/share/classes/sun/font/FileFontStrike.java Changeset: 9318628e8eee Author: jgodinez Date: 2009-03-16 11:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9318628e8eee 6812600: The miter line join decoration isn't rendered properly Reviewed-by: avu, flar Contributed-by: Google ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/JoinMiterTest.java Changeset: 467e4f25965c Author: avu Date: 2009-03-20 20:05 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/467e4f25965c 6733501: Apply IcedTea little cms patches Reviewed-by: bae, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/lcms.h + test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java Changeset: e43ea83ca696 Author: prr Date: 2009-03-23 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e43ea83ca696 6745225: Memory leak while drawing Attributed String Reviewed-by: jgodinez, dougfelt ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/GlyphLayout.java + test/java/awt/font/LineBreakMeasurer/FRCTest.java Changeset: e2cc7ffbb355 Author: prr Date: 2009-03-24 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e2cc7ffbb355 6821031: Upgrade OpenJDK's LittleCMS version to 1.18 Reviewed-by: bae, igor ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscam97.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/icc34.h ! src/share/native/sun/java2d/cmm/lcms/lcms.h Changeset: 0c69e3ba15f4 Author: prr Date: 2009-03-24 10:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0c69e3ba15f4 6821504: typo in lcmsio.c Reviewed-by: jgodinez ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c Changeset: 8e36b37745d4 Author: lana Date: 2009-03-24 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8e36b37745d4 Merge - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties Changeset: 6ee1e2a1a833 Author: lana Date: 2009-04-07 10:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6ee1e2a1a833 Merge - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties Changeset: 6d74c3f22c74 Author: ohair Date: 2009-03-31 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6d74c3f22c74 6604458: linux_x64-fastdebug-c2 fails on hyperbolic trig tests Reviewed-by: tbell ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/java/fdlibm/Makefile Changeset: 90d1a828b6d1 Author: ohair Date: 2009-03-31 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/90d1a828b6d1 6745361: Add -XX options to prevent stdout/stderr pollution using fastdebug/debug bootjdk Reviewed-by: tbell ! make/common/shared/Defs-java.gmk Changeset: 43124654f2aa Author: ohair Date: 2009-03-31 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/43124654f2aa 6502548: test/Makefile needs to be setup to allow for JPRT testrules (NSK and JCK testing too?) Summary: A work in progress on testing additions for JPRT system. Reviewed-by: tbell ! test/Makefile Changeset: b2530d839ecb Author: ohair Date: 2009-03-31 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b2530d839ecb 6824012: Add jdk regression tests to default jprt jobs Summary: A work in progress on adding to the jprt testing. Reviewed-by: tbell ! make/jprt.properties ! test/java/io/File/GetXSpace.java ! test/java/lang/Thread/StartOOMTest.java ! test/java/util/logging/LoggingDeadlock2.java Changeset: 70c53bc9a49d Author: ohair Date: 2009-04-01 09:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/70c53bc9a49d 6824583: regtest TimeUnit/Basic.java fails intermittently on Windows - again Reviewed-by: dholmes ! test/java/util/concurrent/TimeUnit/Basic.java Changeset: 817bb60fbc26 Author: ohair Date: 2009-04-01 09:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/817bb60fbc26 Merge Changeset: f7ca3dad31a2 Author: ohair Date: 2009-04-01 09:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f7ca3dad31a2 Merge - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java Changeset: ce73dcf13656 Author: ohair Date: 2009-04-01 18:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ce73dcf13656 Merge Changeset: 78fbc0dad111 Author: ohair Date: 2009-04-02 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/78fbc0dad111 6825765: Further adjustments to regression tests run by jprt Reviewed-by: tbell ! test/java/lang/reflect/Method/InheritedMethods.java Changeset: f3381dd0f7cd Author: xdono Date: 2009-04-07 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f3381dd0f7cd Merge Changeset: d1c43d1f5676 Author: xdono Date: 2009-04-07 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d1c43d1f5676 Merge - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties Changeset: a43b2c9dad6f Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a43b2c9dad6f Added tag jdk7-b54 for changeset d1c43d1f5676 ! .hgtags From john.coomes at sun.com Thu Apr 9 22:58:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 10 Apr 2009 05:58:06 +0000 Subject: hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b54 for changeset 197a7f881937 Message-ID: <20090410055809.B0F1CE81A@hg.openjdk.java.net> Changeset: 2734c6a91b8b Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/2734c6a91b8b Added tag jdk7-b54 for changeset 197a7f881937 ! .hgtags From jed at atlassian.com Mon Apr 13 21:53:20 2009 From: jed at atlassian.com (Jed Wesley-Smith) Date: Tue, 14 Apr 2009 14:53:20 +1000 Subject: the amazing tales of the search for the invisible man! or, where's my gc root Message-ID: <49E416C0.2090808@atlassian.com> all, I am writing to this list in some desperation hoping for some expert advice. We (the JIRA development team at Atlassian) have been hunting memory leaks for some weeks and in the process have tracked down and removed every possible reference to a large section of memory (a plugin framework) that we could find. Starting with all strong references and proceeding to remove soft and weak references - even things like clearing the java.lang.reflect.Proxy cache - and even Finalizer references until both YourKit, Eclipse MAT, JProfiler and jhat all report that the memory in question is dead and should be collectable, but inexplicably _the JVM still holds on to it_. There are no JNI Global references either, yet this memory remains uncollectable! This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM 1.6 JDK on Linux. So my question is, how on earth do I search for what is referencing this uncollectable memory? Are there any other tools that can help find why this memory is not collected? Can I query the VM directly somehow? I fear this is a JVM GC bug as no known memory analysis tool can find the heap root (i.e. according to "the rules" there is no heap root). Are there any known GC memory leaks caused by ClassLoaders being dropped for instance? The application is creating and disposing of a lot of ClassLoaders via OSGi (Apache Felix) with Spring OSGi. It creates a lot of java.lang.reflect.Proxy class instances. We have written this up and added an example heap dump here: http://jira.atlassian.com/browse/JRA-16932 Having come to the end of our tethers here, if anyone can help in any way it would be massively appreciated. cheers, Jed Wesley-Smith JIRA Team @ Atlassian From Mark_R_Maxey at raytheon.com Tue Apr 14 06:45:25 2009 From: Mark_R_Maxey at raytheon.com (Mark R Maxey) Date: Tue, 14 Apr 2009 08:45:25 -0500 Subject: Garbage Collection Pauses & Non-interruptable System Calls Message-ID: Hello, I have a problem I was hoping with which I need some advice. We wrote a custom JNI library for file I/O that sits underneath the Java NIO FileChannel. One of our driving requirements is highly performant file I/O. We achieved this by doing DMA I/O from large direct memory aligned buffers. The JNI is very trivial - it just takes a buffer and performs the appropriate system call based on the parameters given to it. 100% of the logic for calculating offsets, buffer management, etc. is all in our implementation of java.nio.FileChannel. Here's our problem: We have requirements to respond to some messages in as little as 250 ms. During this time, we're doing file writes of 128 MB that take around 200 ms. When GC kicks in, it tries to pause all threads. Because the DMA write is non-interruptable, GC waits for the I/O to complete before being able to pause the thread & run. That means that GC can take well over 200 ms putting us in grave danger of missing our timelines. Worse, there is always the chance the write will hang due to a bad filesystem. We've seen this cause the JVM to hang indefinitely forcing us to cycle the process. Unless we find a solution that allows GC to continue while doing this I/O, we will convert all the code to C++. While that might solve our timeline for that particular process, we have many less performance critical processes that use our JNI FileChannel libraries that would hang if a filesystem goes bad. We've tweaked the file system device timeouts down to a minimum, but they are still very high (on the order of several seconds to minutes). It would be nice if the JVM had a similar timeout for pausing threads, i.e., where the pause times out after X number of milliseconds. We'd be willing to sacrifice a larger heap size and postpone GC in the hopes that the next time it ran GC, we wouldn't be in the middle of a non-interruptable system call. The only solution being batted around here is pushing the system calls out of Java threads and into native threads. The JNI call would push the info for the I/O call onto a native C++ queue where a small number of native threads (3?) would pull the data off the queue and perform the actual system call. The trick is finding an implementation where the Java thread blocked waiting on a response from the native thread is interruptible. All this assumes GC doesn't try to pause native threads. We thought about using pthreads, but were concerned about its signal interaction with the JVM. So, we're leaning towards using pipes to push data from one thread to another. If you have any suggestions or advice, we are desperate for your wisdom. Thanks! Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090414/24f5c3fd/attachment.html From dragonken at gmail.com Tue Apr 14 08:04:57 2009 From: dragonken at gmail.com (Ken--@newsgroupstats.hk) Date: Tue, 14 Apr 2009 08:04:57 -0700 (PDT) Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E416C0.2090808@atlassian.com> References: <49E416C0.2090808@atlassian.com> Message-ID: <23041258.post@talk.nabble.com> Hi, What are your jvm startup options? Have you try press the "GC" button in JConsole and see those garbage can be collected? Have you turn on DisableExplicitGC? If so, try to invoke a command to your jvm to see those garbage can be collected? jmap -histo:live [pid] Regards, Ken Jed Wesley-Smith wrote: > > all, > > I am writing to this list in some desperation hoping for some expert > advice. We (the JIRA development team at Atlassian) have been hunting > memory leaks for some weeks and in the process have tracked down and > removed every possible reference to a large section of memory (a plugin > framework) that we could find. Starting with all strong references and > proceeding to remove soft and weak references - even things like > clearing the java.lang.reflect.Proxy cache - and even Finalizer > references until both YourKit, Eclipse MAT, JProfiler and jhat all > report that the memory in question is dead and should be collectable, > but inexplicably _the JVM still holds on to it_. There are no JNI Global > references either, yet this memory remains uncollectable! > > This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM 1.6 > JDK on Linux. > > So my question is, how on earth do I search for what is referencing this > uncollectable memory? Are there any other tools that can help find why > this memory is not collected? Can I query the VM directly somehow? > > I fear this is a JVM GC bug as no known memory analysis tool can find > the heap root (i.e. according to "the rules" there is no heap root). Are > there any known GC memory leaks caused by ClassLoaders being dropped for > instance? > > The application is creating and disposing of a lot of ClassLoaders via > OSGi (Apache Felix) with Spring OSGi. It creates a lot of > java.lang.reflect.Proxy class instances. > > We have written this up and added an example heap dump here: > http://jira.atlassian.com/browse/JRA-16932 > > Having come to the end of our tethers here, if anyone can help in any > way it would be massively appreciated. > > cheers, > Jed Wesley-Smith > JIRA Team @ Atlassian > > -- View this message in context: http://www.nabble.com/the-amazing-tales-of-the-search-for-the-invisible-man%21-or%2C-where%27s-my-gc-root-tp23033233p23041258.html Sent from the OpenJDK Hotspot Garbage Collection mailing list archive at Nabble.com. From Y.S.Ramakrishna at Sun.COM Tue Apr 14 08:13:21 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Tue, 14 Apr 2009 08:13:21 -0700 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: References: Message-ID: <49E4A811.8090803@sun.com> Hello Mark -- I am assuming your threads doing DMA are actually executing native code (or waiting for signals in native code). Threads in native code do not need to synchronize \in any manner with GC while they are executing native code. It is only the transitions to and from native mode (from Java code) that require synchronization. Roughly speaking, the JVM fences off those native threads so that, in the event that they need to re-enter the JVM or access the Java heap, they will be suspended until a GC/safepoint that is in progress is completed. Thus, I do not believe you need to fear that a long-running DMA call would cause GC's to be delayed (which I understand is your main concern below). Have you actually seen cases where this is happening? If so, what version of the JDK are you running? thanks. -- ramki Mark R Maxey wrote: > Hello, > > I have a problem I was hoping with which I need some advice. > > We wrote a custom JNI library for file I/O that sits underneath the Java > NIO FileChannel. One of our driving requirements is highly performant > file I/O. We achieved this by doing DMA I/O from large direct memory > aligned buffers. The JNI is very trivial - it just takes a buffer and > performs the appropriate system call based on the parameters given to it. > 100% of the logic for calculating offsets, buffer management, etc. is all > in our implementation of java.nio.FileChannel. > > Here's our problem: We have requirements to respond to some messages in > as little as 250 ms. During this time, we're doing file writes of 128 MB > that take around 200 ms. When GC kicks in, it tries to pause all threads. > Because the DMA write is non-interruptable, GC waits for the I/O to > complete before being able to pause the thread & run. That means that GC > can take well over 200 ms putting us in grave danger of missing our > timelines. Worse, there is always the chance the write will hang due to a > bad filesystem. We've seen this cause the JVM to hang indefinitely > forcing us to cycle the process. > > Unless we find a solution that allows GC to continue while doing this I/O, > we will convert all the code to C++. While that might solve our timeline > for that particular process, we have many less performance critical > processes that use our JNI FileChannel libraries that would hang if a > filesystem goes bad. > > We've tweaked the file system device timeouts down to a minimum, but they > are still very high (on the order of several seconds to minutes). It > would be nice if the JVM had a similar timeout for pausing threads, i.e., > where the pause times out after X number of milliseconds. We'd be willing > to sacrifice a larger heap size and postpone GC in the hopes that the next > time it ran GC, we wouldn't be in the middle of a non-interruptable system > call. > > The only solution being batted around here is pushing the system calls out > of Java threads and into native threads. The JNI call would push the info > for the I/O call onto a native C++ queue where a small number of native > threads (3?) would pull the data off the queue and perform the actual > system call. The trick is finding an implementation where the Java > thread blocked waiting on a response from the native thread is > interruptible. All this assumes GC doesn't try to pause native threads. > We thought about using pthreads, but were concerned about its signal > interaction with the JVM. So, we're leaning towards using pipes to push > data from one thread to another. > > If you have any suggestions or advice, we are desperate for your wisdom. > > Thanks! > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > From Jon.Masamitsu at Sun.COM Tue Apr 14 11:14:32 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 14 Apr 2009 11:14:32 -0700 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime Message-ID: <49E4D288.7070001@Sun.COM> Question: Do users care about applications times output for PrintGCApplicationConcurrentTime only relative to GC's? I have a CR 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate where the complaint is that the application time as output for PrintGCApplicationConcurrentTime does not match the time as measured by the time between GC timestamps. Actually the user is adding up all the times reported for PrintGCApplicationConcurrentTime between the GC timestamps and saying that that sum can be vastly off from the time between GC timestamps. And the user is right. I think the problem is that the timers used to report PrintGCApplicationConcurrentTime are updated more often than the PrintGCApplicationConcurrentTime time is reported. In VMThread::loop() in share/vm/runtime/vmThread.cpp around line 425 the PrintGCApplicationConcurrentTime is reported before the call to SafepointSynchronize::begin(). Whereas near line 391 and near line 520 calls to SafepointSynchronize::begin() do not report for PrintGCApplicationConcurrentTime. The calls to SafepointSynchronize::begin() will update the application timer (_app_timer via a call to RuntimeService::record_safepoint_begin()). Updating resets the timer to the current time and the PrintGCApplicationConcurrentTime output is then the time since the last safepoint (not since the application restarted after the last GC). So anyone know why the PrintGCApplicationConcurrentTime output does not print for all safepoints? Should it only printout when a VM operation is executed as it does now? If yes, should the spelling of PrintGCApplicationConcurrentTime be changed to drop the GC, PrintApplicationConcurrentTime. Similarly with PrintGCApplicationStoppedTime -> PrintApplicationStoppedTime. Or should it printout for all safepoints? This is simpler in that the printing could be added to RuntimeService::record_safepoint_begin()) so we would not miss new safepoints. But we might be dumping useless information. Or I could hack the code so that information is only printed around GC's. And maybe not printout some useful information. From Mark_R_Maxey at raytheon.com Tue Apr 14 10:37:11 2009 From: Mark_R_Maxey at raytheon.com (Mark R Maxey) Date: Tue, 14 Apr 2009 12:37:11 -0500 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: <49E4A811.8090803@sun.com> Message-ID: Thank you for your reply. The speed and depth of your response is encouraging. Let me confess something I should have done up-front. The behavior we're seeing is using JDK 5 via JRockit R27.6. We're in the process of reproducing these problems under HotSpot JDK 6 Update 12, though it'll be a few days before we can do so. The reason I'm pinging this forum is to research in advance what differences we might expect between the two JVMs. Let me describe exactly what we're seeing as provided by doing an strace on the process: A Java thread calls a native C code that ultimately calls a pwrite(). We suspect that the device driver ultimately makes a non-interruptable system call to transfer the data directly from our mem-aligned 128 MB buffer to disk. The GC thread sends a tgkill(SIGUSR1) to all threads The GC thread waits on mutex #1 (presumably waiting on all the threads to signal it that it can begin GC) The Java thread wakes mutex #1 (presumably signaling the GC it is ready to go) The Java thread waits on mutex #2 (presumably waiting on GC to finish) The GC thread wakes mutex #2 (presumably telling the Java thread it can resume processing) We're seeing times between #3 & #4 that are proportional to the amount of time spent in the pwrite(). We also see some overhead between #5  that is proportional to the number of Java threads we have (currently between 30 & 40 that we've created not counting the JVMs). Unfortunately, the JRockit logging only reveals the actual time GC takes (#4 - #5). Hopefully, HotSpot's logging includes the total time (#2 - #6). I'm pursuing these questions with Oracle/BEA. Again, I'm just trying get a feel for HotSpot's behavior in comparison. While we're using JRockit today, HotSpot will be our ultimate platform. One alternate solution that has been suggested is infrequently calling GC explicitly within our code during special times when we know we can afford to take the hit. We would even accept a greater hit than normal if we could avoid being impacted during critical times. Everything I've ever read says to not do this, but I'm curious why in this case this is a bad idea. Note that we're using the concurrent GC, so I'm not even sure if System.gc() supports this. Thanks again! Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com "Y. Srinivas Ramakrishna" Sent by: Y.S.Ramakrishna at Sun.COM 04/14/2009 10:19 AM To Mark R Maxey cc hotspot-gc-dev at openjdk.java.net Subject Re: Garbage Collection Pauses & Non-interruptable System Calls Hello Mark -- I am assuming your threads doing DMA are actually executing native code (or waiting for signals in native code). Threads in native code do not need to synchronize \in any manner with GC while they are executing native code. It is only the transitions to and from native mode (from Java code) that require synchronization. Roughly speaking, the JVM fences off those native threads so that, in the event that they need to re-enter the JVM or access the Java heap, they will be suspended until a GC/safepoint that is in progress is completed. Thus, I do not believe you need to fear that a long-running DMA call would cause GC's to be delayed (which I understand is your main concern below). Have you actually seen cases where this is happening? If so, what version of the JDK are you running? thanks. -- ramki Mark R Maxey wrote: > Hello, > > I have a problem I was hoping with which I need some advice. > > We wrote a custom JNI library for file I/O that sits underneath the Java > NIO FileChannel. One of our driving requirements is highly performant > file I/O. We achieved this by doing DMA I/O from large direct memory > aligned buffers. The JNI is very trivial - it just takes a buffer and > performs the appropriate system call based on the parameters given to it. > 100% of the logic for calculating offsets, buffer management, etc. is all > in our implementation of java.nio.FileChannel. > > Here's our problem: We have requirements to respond to some messages in > as little as 250 ms. During this time, we're doing file writes of 128 MB > that take around 200 ms. When GC kicks in, it tries to pause all threads. > Because the DMA write is non-interruptable, GC waits for the I/O to > complete before being able to pause the thread & run. That means that GC > can take well over 200 ms putting us in grave danger of missing our > timelines. Worse, there is always the chance the write will hang due to a > bad filesystem. We've seen this cause the JVM to hang indefinitely > forcing us to cycle the process. > > Unless we find a solution that allows GC to continue while doing this I/O, > we will convert all the code to C++. While that might solve our timeline > for that particular process, we have many less performance critical > processes that use our JNI FileChannel libraries that would hang if a > filesystem goes bad. > > We've tweaked the file system device timeouts down to a minimum, but they > are still very high (on the order of several seconds to minutes). It > would be nice if the JVM had a similar timeout for pausing threads, i.e., > where the pause times out after X number of milliseconds. We'd be willing > to sacrifice a larger heap size and postpone GC in the hopes that the next > time it ran GC, we wouldn't be in the middle of a non-interruptable system > call. > > The only solution being batted around here is pushing the system calls out > of Java threads and into native threads. The JNI call would push the info > for the I/O call onto a native C++ queue where a small number of native > threads (3?) would pull the data off the queue and perform the actual > system call. The trick is finding an implementation where the Java > thread blocked waiting on a response from the native thread is > interruptible. All this assumes GC doesn't try to pause native threads. > We thought about using pthreads, but were concerned about its signal > interaction with the JVM. So, we're leaning towards using pipes to push > data from one thread to another. > > If you have any suggestions or advice, we are desperate for your wisdom. > > Thanks! > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090414/2e674589/attachment.html From Mark_R_Maxey at raytheon.com Tue Apr 14 11:33:48 2009 From: Mark_R_Maxey at raytheon.com (Mark R Maxey) Date: Tue, 14 Apr 2009 13:33:48 -0500 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: Message-ID: After reading the last paragraph of HotSpot Runtime Overview of JNI more closely, I understand more. I think we're almost on the same page. The problem seems to be that all threads are suspended until the Java thread returns from the native call. Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com Mark R Maxey/US/Raytheon 04/14/2009 12:37 PM To "Y. Srinivas Ramakrishna" cc hotspot-gc-dev at openjdk.java.net, Y.S.Ramakrishna at Sun.COM, Andrew M Dungan/US/Raytheon at MAIL, David A Lilly/RCS/Raytheon/US at MAIL, Mark R Maxey/US/Raytheon at MAIL Subject Re: Garbage Collection Pauses & Non-interruptable System Calls Thank you for your reply. The speed and depth of your response is encouraging. Let me confess something I should have done up-front. The behavior we're seeing is using JDK 5 via JRockit R27.6. We're in the process of reproducing these problems under HotSpot JDK 6 Update 12, though it'll be a few days before we can do so. The reason I'm pinging this forum is to research in advance what differences we might expect between the two JVMs. Let me describe exactly what we're seeing as provided by doing an strace on the process: A Java thread calls a native C code that ultimately calls a pwrite(). We suspect that the device driver ultimately makes a non-interruptable system call to transfer the data directly from our mem-aligned 128 MB buffer to disk. The GC thread sends a tgkill(SIGUSR1) to all threads The GC thread waits on mutex #1 (presumably waiting on all the threads to signal it that it can begin GC) The Java thread wakes mutex #1 (presumably signaling the GC it is ready to go) The Java thread waits on mutex #2 (presumably waiting on GC to finish) The GC thread wakes mutex #2 (presumably telling the Java thread it can resume processing) We're seeing times between #3 & #4 that are proportional to the amount of time spent in the pwrite(). We also see some overhead between #5  that is proportional to the number of Java threads we have (currently between 30 & 40 that we've created not counting the JVMs). Unfortunately, the JRockit logging only reveals the actual time GC takes (#4 - #5). Hopefully, HotSpot's logging includes the total time (#2 - #6). I'm pursuing these questions with Oracle/BEA. Again, I'm just trying get a feel for HotSpot's behavior in comparison. While we're using JRockit today, HotSpot will be our ultimate platform. One alternate solution that has been suggested is infrequently calling GC explicitly within our code during special times when we know we can afford to take the hit. We would even accept a greater hit than normal if we could avoid being impacted during critical times. Everything I've ever read says to not do this, but I'm curious why in this case this is a bad idea. Note that we're using the concurrent GC, so I'm not even sure if System.gc() supports this. Thanks again! Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com "Y. Srinivas Ramakrishna" Sent by: Y.S.Ramakrishna at Sun.COM 04/14/2009 10:19 AM To Mark R Maxey cc hotspot-gc-dev at openjdk.java.net Subject Re: Garbage Collection Pauses & Non-interruptable System Calls Hello Mark -- I am assuming your threads doing DMA are actually executing native code (or waiting for signals in native code). Threads in native code do not need to synchronize \in any manner with GC while they are executing native code. It is only the transitions to and from native mode (from Java code) that require synchronization. Roughly speaking, the JVM fences off those native threads so that, in the event that they need to re-enter the JVM or access the Java heap, they will be suspended until a GC/safepoint that is in progress is completed. Thus, I do not believe you need to fear that a long-running DMA call would cause GC's to be delayed (which I understand is your main concern below). Have you actually seen cases where this is happening? If so, what version of the JDK are you running? thanks. -- ramki Mark R Maxey wrote: > Hello, > > I have a problem I was hoping with which I need some advice. > > We wrote a custom JNI library for file I/O that sits underneath the Java > NIO FileChannel. One of our driving requirements is highly performant > file I/O. We achieved this by doing DMA I/O from large direct memory > aligned buffers. The JNI is very trivial - it just takes a buffer and > performs the appropriate system call based on the parameters given to it. > 100% of the logic for calculating offsets, buffer management, etc. is all > in our implementation of java.nio.FileChannel. > > Here's our problem: We have requirements to respond to some messages in > as little as 250 ms. During this time, we're doing file writes of 128 MB > that take around 200 ms. When GC kicks in, it tries to pause all threads. > Because the DMA write is non-interruptable, GC waits for the I/O to > complete before being able to pause the thread & run. That means that GC > can take well over 200 ms putting us in grave danger of missing our > timelines. Worse, there is always the chance the write will hang due to a > bad filesystem. We've seen this cause the JVM to hang indefinitely > forcing us to cycle the process. > > Unless we find a solution that allows GC to continue while doing this I/O, > we will convert all the code to C++. While that might solve our timeline > for that particular process, we have many less performance critical > processes that use our JNI FileChannel libraries that would hang if a > filesystem goes bad. > > We've tweaked the file system device timeouts down to a minimum, but they > are still very high (on the order of several seconds to minutes). It > would be nice if the JVM had a similar timeout for pausing threads, i.e., > where the pause times out after X number of milliseconds. We'd be willing > to sacrifice a larger heap size and postpone GC in the hopes that the next > time it ran GC, we wouldn't be in the middle of a non-interruptable system > call. > > The only solution being batted around here is pushing the system calls out > of Java threads and into native threads. The JNI call would push the info > for the I/O call onto a native C++ queue where a small number of native > threads (3?) would pull the data off the queue and perform the actual > system call. The trick is finding an implementation where the Java > thread blocked waiting on a response from the native thread is > interruptible. All this assumes GC doesn't try to pause native threads. > We thought about using pthreads, but were concerned about its signal > interaction with the JVM. So, we're leaning towards using pipes to push > data from one thread to another. > > If you have any suggestions or advice, we are desperate for your wisdom. > > Thanks! > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090414/5c98129f/attachment.html From Paul.Hohensee at Sun.COM Tue Apr 14 15:06:22 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Tue, 14 Apr 2009 18:06:22 -0400 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: References: Message-ID: <49E508DE.6060300@sun.com> The url for "Hotspot Runtime Overview of JNI" didn't come through for me. In any case, as Ramki noted, Hotspot lets native code called from Java run free during GC pauses, unless said native code calls back into the jvm for some reason, including just returning back to Java from native. Hotspot does _not_ try to pause threads executing native code, nor does Hotspot use signal mechanisms to block threads executing Java code so GC can happen. Hotspot uses a polling mechanism instead because signal delivery mechanisms on Unix and Linux are unreliable. I doubt you'll be able to reproduce the JRockit issue with Hotspot. You might have other problems, but not that one. I suggest forwarding your questions to the JRockit team at Oracle. Though I suspect some of them are on this list too. :) Please try Hotspot before you give up on Java. From your description, you should use the CMS (concurrent mark-sweep) collector. See also the GC performance info accessible from http://java.sun.com/performance and Jon Masamitsu's blog http://blogs.sun.com/jonthecollector/ Paul Mark R Maxey wrote: > > After reading the last paragraph of HotSpot Runtime Overview of JNI > more closely, I understand more. I think we're almost on the same > page. The problem seems to be that all threads are suspended until > the Java thread returns from the native call. > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > > *Mark R Maxey/US/Raytheon* > > 04/14/2009 12:37 PM > > > To > "Y. Srinivas Ramakrishna" > cc > hotspot-gc-dev at openjdk.java.net, Y.S.Ramakrishna at Sun.COM, Andrew M > Dungan/US/Raytheon at MAIL, David A Lilly/RCS/Raytheon/US at MAIL, Mark R > Maxey/US/Raytheon at MAIL > Subject > Re: Garbage Collection Pauses & Non-interruptable System CallsLink > > > > > > > > > > > Thank you for your reply. The speed and depth of your response is > encouraging. > > Let me confess something I should have done up-front. The behavior > we're seeing is using JDK 5 via JRockit R27.6. We're in the process > of reproducing these problems under HotSpot JDK 6 Update 12, though > it'll be a few days before we can do so. The reason I'm pinging this > forum is to research in advance what differences we might expect > between the two JVMs. > > Let me describe exactly what we're seeing as provided by doing an > strace on the process: > > 1. A Java thread calls a native C code that ultimately calls a > pwrite(). We suspect that the device driver ultimately makes a > non-interruptable system call to transfer the data directly from > our mem-aligned 128 MB buffer to disk. > 2. The GC thread sends a tgkill(SIGUSR1) to all threads > 3. The GC thread waits on mutex #1 (presumably waiting on all the > threads to signal it that it can begin GC) > 4. The Java thread wakes mutex #1 (presumably signaling the GC it > is ready to go) > 5. The Java thread waits on mutex #2 (presumably waiting on GC to > finish) > 6. The GC thread wakes mutex #2 (presumably telling the Java thread > it can resume processing) > > > We're seeing times between #3 & #4 that are proportional to the amount > of time spent in the pwrite(). We also see some overhead between #5 >  that is proportional to the number of Java threads we have > (currently between 30 & 40 that we've created not counting the JVMs). > > Unfortunately, the JRockit logging only reveals the actual time GC > takes (#4 - #5). Hopefully, HotSpot's logging includes the total time > (#2 - #6). > > I'm pursuing these questions with Oracle/BEA. Again, I'm just trying > get a feel for HotSpot's behavior in comparison. While we're using > JRockit today, HotSpot will be our ultimate platform. > > > One alternate solution that has been suggested is infrequently calling > GC explicitly within our code during special times when we know we can > afford to take the hit. We would even accept a greater hit than > normal if we could avoid being impacted during critical times. > Everything I've ever read says to not do this, but I'm curious why in > this case this is a bad idea. Note that we're using the concurrent > GC, so I'm not even sure if System.gc() supports this. > > > Thanks again! > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > > *"Y. Srinivas Ramakrishna" * > Sent by: Y.S.Ramakrishna at Sun.COM > > 04/14/2009 10:19 AM > > > To > Mark R Maxey > cc > hotspot-gc-dev at openjdk.java.net > Subject > Re: Garbage Collection Pauses & Non-interruptable System Calls > > > > > > > > > > Hello Mark -- > > I am assuming your threads doing DMA are actually executing native > code (or > waiting for signals in native code). Threads in native code do not > need to > synchronize \in any manner with GC while they are executing native code. > It is only the transitions to and from native mode (from Java code) that > require > synchronization. Roughly speaking, the JVM fences off those native > threads so that, in the event that they need to re-enter the JVM or > access the Java heap, they will be suspended until a GC/safepoint that > is in progress is completed. > > Thus, I do not believe you need to fear that a long-running DMA call would > cause GC's to be delayed (which I understand is your main concern below). > > Have you actually seen cases where this is happening? If so, what > version of the JDK > are you running? > > thanks. > -- ramki > > Mark R Maxey wrote: > > Hello, > > > > I have a problem I was hoping with which I need some advice. > > > > We wrote a custom JNI library for file I/O that sits underneath the > Java > > NIO FileChannel. One of our driving requirements is highly performant > > file I/O. We achieved this by doing DMA I/O from large direct memory > > aligned buffers. The JNI is very trivial - it just takes a buffer and > > performs the appropriate system call based on the parameters given > to it. > > 100% of the logic for calculating offsets, buffer management, etc. > is all > > in our implementation of java.nio.FileChannel. > > > > Here's our problem: We have requirements to respond to some > messages in > > as little as 250 ms. During this time, we're doing file writes of > 128 MB > > that take around 200 ms. When GC kicks in, it tries to pause all > threads. > > Because the DMA write is non-interruptable, GC waits for the I/O to > > complete before being able to pause the thread & run. That means > that GC > > can take well over 200 ms putting us in grave danger of missing our > > timelines. Worse, there is always the chance the write will hang > due to a > > bad filesystem. We've seen this cause the JVM to hang indefinitely > > forcing us to cycle the process. > > > > Unless we find a solution that allows GC to continue while doing > this I/O, > > we will convert all the code to C++. While that might solve our > timeline > > for that particular process, we have many less performance critical > > processes that use our JNI FileChannel libraries that would hang if a > > filesystem goes bad. > > > > We've tweaked the file system device timeouts down to a minimum, but > they > > are still very high (on the order of several seconds to minutes). It > > would be nice if the JVM had a similar timeout for pausing threads, > i.e., > > where the pause times out after X number of milliseconds. We'd be > willing > > to sacrifice a larger heap size and postpone GC in the hopes that > the next > > time it ran GC, we wouldn't be in the middle of a non-interruptable > system > > call. > > > > The only solution being batted around here is pushing the system > calls out > > of Java threads and into native threads. The JNI call would push > the info > > for the I/O call onto a native C++ queue where a small number of native > > threads (3?) would pull the data off the queue and perform the actual > > system call. The trick is finding an implementation where the Java > > thread blocked waiting on a response from the native thread is > > interruptible. All this assumes GC doesn't try to pause native > threads. > > We thought about using pthreads, but were concerned about its signal > > interaction with the JVM. So, we're leaning towards using pipes to > push > > data from one thread to another. > > > > If you have any suggestions or advice, we are desperate for your wisdom. > > > > Thanks! > > > > > > Mark Maxey > > Raytheon, Garland > > 580/2/P22-1 > > (972)205-5760 > > Mark_R_Maxey at Raytheon.com > > > > > > > > > From john.pampuch at sun.com Tue Apr 14 15:19:27 2009 From: john.pampuch at sun.com (John Pampuch) Date: Tue, 14 Apr 2009 15:19:27 -0700 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: <49E508DE.6060300@sun.com> References: <49E508DE.6060300@sun.com> Message-ID: <49E50BEF.2030205@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090414/9159ce27/attachment.html From Mark_R_Maxey at raytheon.com Tue Apr 14 15:30:03 2009 From: Mark_R_Maxey at raytheon.com (Mark R Maxey) Date: Tue, 14 Apr 2009 17:30:03 -0500 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: <49E50BEF.2030205@sun.com> Message-ID: Thanks you for your suggestion. Yes, we real-time Java has been considered. Unfortunately, it is not supported on our SUSE 10 64 bit Itanium chip set. I've had a series of email exchanges with Gregory Bollella. If even a fraction of the claims are true, we would be very interested when the time comes to change our machines over to a x86 chip set. Thanks again, Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com John Pampuch Sent by: John.C.Pampuch at sun.com 04/14/2009 05:19 PM To Paul Hohensee cc Mark R Maxey , hotspot-gc-dev at openjdk.java.net, Andrew M Dungan , "Y. Srinivas Ramakrishna" , David A Lilly Subject Re: Garbage Collection Pauses & Non-interruptable System Calls Mark- You've probably already gotten this suggestion, but another alternative to look at is Sun's real-time system. http://java.sun.com/javase/technologies/realtime/index.jsp Right now, we offer a Java 5 compatible release that provides a number of means of managing the impact of GC in an application. It does trade off throughput, but that may not be a barrier in your specific case. It also provides a threading model with fine grained priorities that may be more to your liking It offers a priority inversion protocol as part of the implementation too. -John Paul Hohensee wrote: The url for "Hotspot Runtime Overview of JNI" didn't come through for me. In any case, as Ramki noted, Hotspot lets native code called from Java run free during GC pauses, unless said native code calls back into the jvm for some reason, including just returning back to Java from native. Hotspot does _not_ try to pause threads executing native code, nor does Hotspot use signal mechanisms to block threads executing Java code so GC can happen. Hotspot uses a polling mechanism instead because signal delivery mechanisms on Unix and Linux are unreliable. I doubt you'll be able to reproduce the JRockit issue with Hotspot. You might have other problems, but not that one. I suggest forwarding your questions to the JRockit team at Oracle. Though I suspect some of them are on this list too. :) Please try Hotspot before you give up on Java. From your description, you should use the CMS (concurrent mark-sweep) collector. See also the GC performance info accessible from http://java.sun.com/performance and Jon Masamitsu's blog http://blogs.sun.com/jonthecollector/ Paul Mark R Maxey wrote: After reading the last paragraph of HotSpot Runtime Overview of JNI more closely, I understand more. I think we're almost on the same page. The problem seems to be that all threads are suspended until the Java thread returns from the native call. Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com *Mark R Maxey/US/Raytheon* 04/14/2009 12:37 PM To "Y. Srinivas Ramakrishna" cc hotspot-gc-dev at openjdk.java.net, Y.S.Ramakrishna at Sun.COM, Andrew M Dungan/US/Raytheon at MAIL, David A Lilly/RCS/Raytheon/US at MAIL, Mark R Maxey/US/Raytheon at MAIL Subject Re: Garbage Collection Pauses & Non-interruptable System CallsLink < Notes://MK2-MSG05/86256EF3005F851B/38D46BF5E8F08834852564B500129B2C/E1F59319D41C5C4886257598005422BD > Thank you for your reply. The speed and depth of your response is encouraging. Let me confess something I should have done up-front. The behavior we're seeing is using JDK 5 via JRockit R27.6. We're in the process of reproducing these problems under HotSpot JDK 6 Update 12, though it'll be a few days before we can do so. The reason I'm pinging this forum is to research in advance what differences we might expect between the two JVMs. Let me describe exactly what we're seeing as provided by doing an strace on the process: 1. A Java thread calls a native C code that ultimately calls a pwrite(). We suspect that the device driver ultimately makes a non-interruptable system call to transfer the data directly from our mem-aligned 128 MB buffer to disk. 2. The GC thread sends a tgkill(SIGUSR1) to all threads 3. The GC thread waits on mutex #1 (presumably waiting on all the threads to signal it that it can begin GC) 4. The Java thread wakes mutex #1 (presumably signaling the GC it is ready to go) 5. The Java thread waits on mutex #2 (presumably waiting on GC to finish) 6. The GC thread wakes mutex #2 (presumably telling the Java thread it can resume processing) We're seeing times between #3 & #4 that are proportional to the amount of time spent in the pwrite(). We also see some overhead between #5  that is proportional to the number of Java threads we have (currently between 30 & 40 that we've created not counting the JVMs). Unfortunately, the JRockit logging only reveals the actual time GC takes (#4 - #5). Hopefully, HotSpot's logging includes the total time (#2 - #6). I'm pursuing these questions with Oracle/BEA. Again, I'm just trying get a feel for HotSpot's behavior in comparison. While we're using JRockit today, HotSpot will be our ultimate platform. One alternate solution that has been suggested is infrequently calling GC explicitly within our code during special times when we know we can afford to take the hit. We would even accept a greater hit than normal if we could avoid being impacted during critical times. Everything I've ever read says to not do this, but I'm curious why in this case this is a bad idea. Note that we're using the concurrent GC, so I'm not even sure if System.gc() supports this. Thanks again! Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com *"Y. Srinivas Ramakrishna" * Sent by: Y.S.Ramakrishna at Sun.COM 04/14/2009 10:19 AM To Mark R Maxey cc hotspot-gc-dev at openjdk.java.net Subject Re: Garbage Collection Pauses & Non-interruptable System Calls Hello Mark -- I am assuming your threads doing DMA are actually executing native code (or waiting for signals in native code). Threads in native code do not need to synchronize \in any manner with GC while they are executing native code. It is only the transitions to and from native mode (from Java code) that require synchronization. Roughly speaking, the JVM fences off those native threads so that, in the event that they need to re-enter the JVM or access the Java heap, they will be suspended until a GC/safepoint that is in progress is completed. Thus, I do not believe you need to fear that a long-running DMA call would cause GC's to be delayed (which I understand is your main concern below). Have you actually seen cases where this is happening? If so, what version of the JDK are you running? thanks. -- ramki Mark R Maxey wrote: > Hello, > > I have a problem I was hoping with which I need some advice. > > We wrote a custom JNI library for file I/O that sits underneath the Java > NIO FileChannel. One of our driving requirements is highly performant > file I/O. We achieved this by doing DMA I/O from large direct memory > aligned buffers. The JNI is very trivial - it just takes a buffer and > performs the appropriate system call based on the parameters given to it. > 100% of the logic for calculating offsets, buffer management, etc. is all > in our implementation of java.nio.FileChannel. > > Here's our problem: We have requirements to respond to some messages in > as little as 250 ms. During this time, we're doing file writes of 128 MB > that take around 200 ms. When GC kicks in, it tries to pause all threads. > Because the DMA write is non-interruptable, GC waits for the I/O to > complete before being able to pause the thread & run. That means that GC > can take well over 200 ms putting us in grave danger of missing our > timelines. Worse, there is always the chance the write will hang due to a > bad filesystem. We've seen this cause the JVM to hang indefinitely > forcing us to cycle the process. > > Unless we find a solution that allows GC to continue while doing this I/O, > we will convert all the code to C++. While that might solve our timeline > for that particular process, we have many less performance critical > processes that use our JNI FileChannel libraries that would hang if a > filesystem goes bad. > > We've tweaked the file system device timeouts down to a minimum, but they > are still very high (on the order of several seconds to minutes). It > would be nice if the JVM had a similar timeout for pausing threads, i.e., > where the pause times out after X number of milliseconds. We'd be willing > to sacrifice a larger heap size and postpone GC in the hopes that the next > time it ran GC, we wouldn't be in the middle of a non-interruptable system > call. > > The only solution being batted around here is pushing the system calls out > of Java threads and into native threads. The JNI call would push the info > for the I/O call onto a native C++ queue where a small number of native > threads (3?) would pull the data off the queue and perform the actual > system call. The trick is finding an implementation where the Java > thread blocked waiting on a response from the native thread is > interruptible. All this assumes GC doesn't try to pause native threads. > We thought about using pthreads, but were concerned about its signal > interaction with the JVM. So, we're leaning towards using pipes to push > data from one thread to another. > > If you have any suggestions or advice, we are desperate for your wisdom. > > Thanks! > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090414/041cb4ee/attachment.html From Mark_R_Maxey at raytheon.com Tue Apr 14 15:41:03 2009 From: Mark_R_Maxey at raytheon.com (Mark R Maxey) Date: Tue, 14 Apr 2009 17:41:03 -0500 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: <49E508DE.6060300@sun.com> Message-ID: Here's is the URL I tried to include: http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Java%20Native%20Interface%20(JNI)|outline We are using the concurrent GC with a single generation. After we workaround this immediate issue, we plan to migrate to multiple generations and tweak the sizes of the generations. It is encouraging to hear that HotSpot uses a different algorithm. I'll see what I can do to accellerate its usage. I'd like to understand HotSpot's behavior a little better. It sounds like your algorithm can do the mark & sweep on a Java thread in native code without pausing that thread? Thanks for all the feedback. I'll continue reading ... Mark Maxey Raytheon, Garland 580/2/P22-1 (972)205-5760 Mark_R_Maxey at Raytheon.com Paul Hohensee Sent by: Paul.Hohensee at Sun.COM 04/14/2009 05:06 PM To Mark R Maxey cc "Y. Srinivas Ramakrishna" , hotspot-gc-dev at openjdk.java.net, Andrew M Dungan , David A Lilly Subject Re: Garbage Collection Pauses & Non-interruptable System Calls The url for "Hotspot Runtime Overview of JNI" didn't come through for me. In any case, as Ramki noted, Hotspot lets native code called from Java run free during GC pauses, unless said native code calls back into the jvm for some reason, including just returning back to Java from native. Hotspot does _not_ try to pause threads executing native code, nor does Hotspot use signal mechanisms to block threads executing Java code so GC can happen. Hotspot uses a polling mechanism instead because signal delivery mechanisms on Unix and Linux are unreliable. I doubt you'll be able to reproduce the JRockit issue with Hotspot. You might have other problems, but not that one. I suggest forwarding your questions to the JRockit team at Oracle. Though I suspect some of them are on this list too. :) Please try Hotspot before you give up on Java. From your description, you should use the CMS (concurrent mark-sweep) collector. See also the GC performance info accessible from http://java.sun.com/performance and Jon Masamitsu's blog http://blogs.sun.com/jonthecollector/ Paul Mark R Maxey wrote: > > After reading the last paragraph of HotSpot Runtime Overview of JNI > more closely, I understand more. I think we're almost on the same > page. The problem seems to be that all threads are suspended until > the Java thread returns from the native call. > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > > *Mark R Maxey/US/Raytheon* > > 04/14/2009 12:37 PM > > > To > "Y. Srinivas Ramakrishna" > cc > hotspot-gc-dev at openjdk.java.net, Y.S.Ramakrishna at Sun.COM, Andrew M > Dungan/US/Raytheon at MAIL, David A Lilly/RCS/Raytheon/US at MAIL, Mark R > Maxey/US/Raytheon at MAIL > Subject > Re: Garbage Collection Pauses & Non-interruptable System CallsLink > < Notes://MK2-MSG05/86256EF3005F851B/38D46BF5E8F08834852564B500129B2C/E1F59319D41C5C4886257598005422BD > > > > > > > > > > > Thank you for your reply. The speed and depth of your response is > encouraging. > > Let me confess something I should have done up-front. The behavior > we're seeing is using JDK 5 via JRockit R27.6. We're in the process > of reproducing these problems under HotSpot JDK 6 Update 12, though > it'll be a few days before we can do so. The reason I'm pinging this > forum is to research in advance what differences we might expect > between the two JVMs. > > Let me describe exactly what we're seeing as provided by doing an > strace on the process: > > 1. A Java thread calls a native C code that ultimately calls a > pwrite(). We suspect that the device driver ultimately makes a > non-interruptable system call to transfer the data directly from > our mem-aligned 128 MB buffer to disk. > 2. The GC thread sends a tgkill(SIGUSR1) to all threads > 3. The GC thread waits on mutex #1 (presumably waiting on all the > threads to signal it that it can begin GC) > 4. The Java thread wakes mutex #1 (presumably signaling the GC it > is ready to go) > 5. The Java thread waits on mutex #2 (presumably waiting on GC to > finish) > 6. The GC thread wakes mutex #2 (presumably telling the Java thread > it can resume processing) > > > We're seeing times between #3 & #4 that are proportional to the amount > of time spent in the pwrite(). We also see some overhead between #5 >  that is proportional to the number of Java threads we have > (currently between 30 & 40 that we've created not counting the JVMs). > > Unfortunately, the JRockit logging only reveals the actual time GC > takes (#4 - #5). Hopefully, HotSpot's logging includes the total time > (#2 - #6). > > I'm pursuing these questions with Oracle/BEA. Again, I'm just trying > get a feel for HotSpot's behavior in comparison. While we're using > JRockit today, HotSpot will be our ultimate platform. > > > One alternate solution that has been suggested is infrequently calling > GC explicitly within our code during special times when we know we can > afford to take the hit. We would even accept a greater hit than > normal if we could avoid being impacted during critical times. > Everything I've ever read says to not do this, but I'm curious why in > this case this is a bad idea. Note that we're using the concurrent > GC, so I'm not even sure if System.gc() supports this. > > > Thanks again! > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > > *"Y. Srinivas Ramakrishna" * > Sent by: Y.S.Ramakrishna at Sun.COM > > 04/14/2009 10:19 AM > > > To > Mark R Maxey > cc > hotspot-gc-dev at openjdk.java.net > Subject > Re: Garbage Collection Pauses & Non-interruptable System Calls > > > > > > > > > > Hello Mark -- > > I am assuming your threads doing DMA are actually executing native > code (or > waiting for signals in native code). Threads in native code do not > need to > synchronize \in any manner with GC while they are executing native code. > It is only the transitions to and from native mode (from Java code) that > require > synchronization. Roughly speaking, the JVM fences off those native > threads so that, in the event that they need to re-enter the JVM or > access the Java heap, they will be suspended until a GC/safepoint that > is in progress is completed. > > Thus, I do not believe you need to fear that a long-running DMA call would > cause GC's to be delayed (which I understand is your main concern below). > > Have you actually seen cases where this is happening? If so, what > version of the JDK > are you running? > > thanks. > -- ramki > > Mark R Maxey wrote: > > Hello, > > > > I have a problem I was hoping with which I need some advice. > > > > We wrote a custom JNI library for file I/O that sits underneath the > Java > > NIO FileChannel. One of our driving requirements is highly performant > > file I/O. We achieved this by doing DMA I/O from large direct memory > > aligned buffers. The JNI is very trivial - it just takes a buffer and > > performs the appropriate system call based on the parameters given > to it. > > 100% of the logic for calculating offsets, buffer management, etc. > is all > > in our implementation of java.nio.FileChannel. > > > > Here's our problem: We have requirements to respond to some > messages in > > as little as 250 ms. During this time, we're doing file writes of > 128 MB > > that take around 200 ms. When GC kicks in, it tries to pause all > threads. > > Because the DMA write is non-interruptable, GC waits for the I/O to > > complete before being able to pause the thread & run. That means > that GC > > can take well over 200 ms putting us in grave danger of missing our > > timelines. Worse, there is always the chance the write will hang > due to a > > bad filesystem. We've seen this cause the JVM to hang indefinitely > > forcing us to cycle the process. > > > > Unless we find a solution that allows GC to continue while doing > this I/O, > > we will convert all the code to C++. While that might solve our > timeline > > for that particular process, we have many less performance critical > > processes that use our JNI FileChannel libraries that would hang if a > > filesystem goes bad. > > > > We've tweaked the file system device timeouts down to a minimum, but > they > > are still very high (on the order of several seconds to minutes). It > > would be nice if the JVM had a similar timeout for pausing threads, > i.e., > > where the pause times out after X number of milliseconds. We'd be > willing > > to sacrifice a larger heap size and postpone GC in the hopes that > the next > > time it ran GC, we wouldn't be in the middle of a non-interruptable > system > > call. > > > > The only solution being batted around here is pushing the system > calls out > > of Java threads and into native threads. The JNI call would push > the info > > for the I/O call onto a native C++ queue where a small number of native > > threads (3?) would pull the data off the queue and perform the actual > > system call. The trick is finding an implementation where the Java > > thread blocked waiting on a response from the native thread is > > interruptible. All this assumes GC doesn't try to pause native > threads. > > We thought about using pthreads, but were concerned about its signal > > interaction with the JVM. So, we're leaning towards using pipes to > push > > data from one thread to another. > > > > If you have any suggestions or advice, we are desperate for your wisdom. > > > > Thanks! > > > > > > Mark Maxey > > Raytheon, Garland > > 580/2/P22-1 > > (972)205-5760 > > Mark_R_Maxey at Raytheon.com > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090414/9a018190/attachment.html From mail at nmichael.de Tue Apr 14 23:02:51 2009 From: mail at nmichael.de (Nicolas Michael) Date: Wed, 15 Apr 2009 08:02:51 +0200 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E4D288.7070001@Sun.COM> References: <49E4D288.7070001@Sun.COM> Message-ID: <49E5788B.8040307@nmichael.de> Hi Jon, we have been using PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime to figure out what was going on when one of our processes was blocked for up to 100 seconds around GC's, although GC's only lasted a few hundred ms. It turned out that it sometimes took 100+ seconds to bring all threads to a safepoint. I currently don't remember the bug id, but Ramki probably does. (It's been fixed for 1 or 2 years, now.) For this it's been very useful. Since it includes safepointing time (for GC's), PrintGCApplicationStoppedTime would always be >= the reported GC pause times (which might be confusing if you don't know what PrintGCApplicationStoppedTime is counting -- but if you want to see the GC time, you can look at the GC outputs instead of the StoppedTime ... So that's ok for me!). Other than that we don't use PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime too often. We didn't have problems with other safepoints yet, but if we had (or just to make sure we *don't* have), it would be nice to get some information about the time our mutator threads are blocked, not only due to GC. So reducing the reported times to just those due to GC would mean losing some maybe valuable information (unless you introduce new parameters that count everything again). Since I don't really know what other safepoints you have that are not due to "VM operations" and that are not reported right now, I'm not sure whether I would want to have them in the logs as well every time they occur (depending on how often they occur)... But actually I would prefer to have *all* time due to safepointing reported somehow. In case there is some problem with safepointing, it would be good to have some counters showing that. Or just to see how much time the application is *really* running (vs. being blocked). Reporting all this with PrintGCApplicationStoppedTime and PrintGCApplicationConcurrentTime (and probably drop the "GC" in the name) sounds good to me! Nick. Jon Masamitsu schrieb: > Question: Do users care about applications times output > for PrintGCApplicationConcurrentTime only relative to > GC's? > > > I have a CR > > 6782663: Data produced by PrintGCApplicationConcurrentTime and > PrintGCApplicationStoppedTime is not accurate > > where the complaint is that the application time as output > for PrintGCApplicationConcurrentTime does not match the time > as measured by the time between GC timestamps. Actually the > user is adding up all the times reported for > PrintGCApplicationConcurrentTime between the GC timestamps > and saying that that sum can be vastly off from the > time between GC timestamps. And the user is right. > > I think the problem is that the timers used to report > PrintGCApplicationConcurrentTime are updated more often > than the PrintGCApplicationConcurrentTime time is > reported. In VMThread::loop() in share/vm/runtime/vmThread.cpp > around line 425 the PrintGCApplicationConcurrentTime is > reported before the call to SafepointSynchronize::begin(). > Whereas near line 391 and near line 520 calls to > SafepointSynchronize::begin() do not report for > PrintGCApplicationConcurrentTime. The calls to > SafepointSynchronize::begin() will update the application > timer (_app_timer via a call to > RuntimeService::record_safepoint_begin()). Updating > resets the timer to the current time and the > PrintGCApplicationConcurrentTime output is then the > time since the last safepoint (not since the application > restarted after the last GC). > > So anyone know why the PrintGCApplicationConcurrentTime output > does not print for all safepoints? Should it only printout > when a VM operation is executed as it does now? > > If yes, should the spelling of > PrintGCApplicationConcurrentTime be changed to drop > the GC, PrintApplicationConcurrentTime. Similarly with > PrintGCApplicationStoppedTime -> PrintApplicationStoppedTime. > > Or should it printout for all safepoints? This is > simpler in that the printing could be added to > RuntimeService::record_safepoint_begin()) so > we would not miss new safepoints. But we might > be dumping useless information. > > Or I could hack the code so that information is only > printed around GC's. And maybe not printout some > useful information. > > > From Y.S.Ramakrishna at Sun.COM Tue Apr 14 23:24:09 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Tue, 14 Apr 2009 23:24:09 -0700 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E5788B.8040307@nmichael.de> References: <49E4D288.7070001@Sun.COM> <49E5788B.8040307@nmichael.de> Message-ID: <49E57D89.5020404@sun.com> Nicolas Michael wrote: > ... But actually I would prefer to have *all* time due to safepointing > reported somehow. In case there is some problem with safepointing, it > would be good to have some counters showing that. Or just to see how > much time the application is *really* running (vs. being blocked). > Reporting all this with PrintGCApplicationStoppedTime and > PrintGCApplicationConcurrentTime (and probably drop the "GC" in the > name) sounds good to me! +1: I vote with Nick here. -- ramki > > Nick. > > Jon Masamitsu schrieb: >> Question: Do users care about applications times output >> for PrintGCApplicationConcurrentTime only relative to >> GC's? >> >> >> I have a CR >> >> 6782663: Data produced by PrintGCApplicationConcurrentTime and >> PrintGCApplicationStoppedTime is not accurate >> From David.Holmes at Sun.COM Tue Apr 14 23:58:52 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Wed, 15 Apr 2009 16:58:52 +1000 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E57D89.5020404@sun.com> References: <49E4D288.7070001@Sun.COM> <49E5788B.8040307@nmichael.de> <49E57D89.5020404@sun.com> Message-ID: <49E585AC.2080207@sun.com> We already have PrintSafepointStatistics to give detailed safepoint information. David Holmes Y. Srinivas Ramakrishna said the following on 04/15/09 16:24: > Nicolas Michael wrote: >> ... But actually I would prefer to have *all* time due to safepointing >> reported somehow. In case there is some problem with safepointing, it >> would be good to have some counters showing that. Or just to see how >> much time the application is *really* running (vs. being blocked). >> Reporting all this with PrintGCApplicationStoppedTime and >> PrintGCApplicationConcurrentTime (and probably drop the "GC" in the >> name) sounds good to me! > > +1: I vote with Nick here. > > -- ramki >> >> Nick. >> >> Jon Masamitsu schrieb: >>> Question: Do users care about applications times output >>> for PrintGCApplicationConcurrentTime only relative to >>> GC's? >>> >>> >>> I have a CR >>> >>> 6782663: Data produced by PrintGCApplicationConcurrentTime and >>> PrintGCApplicationStoppedTime is not accurate >>> From Antonios.Printezis at sun.com Wed Apr 15 07:51:18 2009 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Wed, 15 Apr 2009 10:51:18 -0400 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E416C0.2090808@atlassian.com> References: <49E416C0.2090808@atlassian.com> Message-ID: <49E5F466.5020600@sun.com> OK, I'll bite. When you say: "a large section of memory (a plugin framework)" do you mean only objects in the young / old gen, or also classes in the perm gen? How do you know that said memory is not being reclaimed? Do you eventually get an OOM? Given that it happens with two different JVMs (I assume you use HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to be a GC bug, as both JVMs would need to have the same bug. Not impossible, but unlikely, IMHO. Tony Jed Wesley-Smith wrote: > all, > > I am writing to this list in some desperation hoping for some expert > advice. We (the JIRA development team at Atlassian) have been hunting > memory leaks for some weeks and in the process have tracked down and > removed every possible reference to a large section of memory (a > plugin framework) that we could find. Starting with all strong > references and proceeding to remove soft and weak references - even > things like clearing the java.lang.reflect.Proxy cache - and even > Finalizer references until both YourKit, Eclipse MAT, JProfiler and > jhat all report that the memory in question is dead and should be > collectable, but inexplicably _the JVM still holds on to it_. There > are no JNI Global references either, yet this memory remains > uncollectable! > > This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM > 1.6 JDK on Linux. > > So my question is, how on earth do I search for what is referencing > this uncollectable memory? Are there any other tools that can help > find why this memory is not collected? Can I query the VM directly > somehow? > > I fear this is a JVM GC bug as no known memory analysis tool can find > the heap root (i.e. according to "the rules" there is no heap root). > Are there any known GC memory leaks caused by ClassLoaders being > dropped for instance? > > The application is creating and disposing of a lot of ClassLoaders via > OSGi (Apache Felix) with Spring OSGi. It creates a lot of > java.lang.reflect.Proxy class instances. > > We have written this up and added an example heap dump here: > http://jira.atlassian.com/browse/JRA-16932 > > Having come to the end of our tethers here, if anyone can help in any > way it would be massively appreciated. > > cheers, > Jed Wesley-Smith > JIRA Team @ Atlassian -- --------------------------------------------------------------------- | 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 Y.S.Ramakrishna at Sun.COM Wed Apr 15 09:27:53 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Wed, 15 Apr 2009 09:27:53 -0700 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E4D288.7070001@Sun.COM> References: <49E4D288.7070001@Sun.COM> Message-ID: <49E60B09.5070009@sun.com> If you do extend it to all safepoints, please consider adding an event time-stamp with the non-GC events which currently do not carry a timestamp. Otherwise, as David said, I hope all of that information can be obtained from PrintSafepointstatistics. -- ramki Jon Masamitsu wrote: > Question: Do users care about applications times output > for PrintGCApplicationConcurrentTime only relative to > GC's? > > > I have a CR > > 6782663: Data produced by PrintGCApplicationConcurrentTime and > PrintGCApplicationStoppedTime is not accurate > > where the complaint is that the application time as output > for PrintGCApplicationConcurrentTime does not match the time > as measured by the time between GC timestamps. Actually the > user is adding up all the times reported for > PrintGCApplicationConcurrentTime between the GC timestamps > and saying that that sum can be vastly off from the > time between GC timestamps. And the user is right. > > I think the problem is that the timers used to report > PrintGCApplicationConcurrentTime are updated more often > than the PrintGCApplicationConcurrentTime time is > reported. In VMThread::loop() in share/vm/runtime/vmThread.cpp > around line 425 the PrintGCApplicationConcurrentTime is > reported before the call to SafepointSynchronize::begin(). > Whereas near line 391 and near line 520 calls to > SafepointSynchronize::begin() do not report for > PrintGCApplicationConcurrentTime. The calls to > SafepointSynchronize::begin() will update the application > timer (_app_timer via a call to > RuntimeService::record_safepoint_begin()). Updating > resets the timer to the current time and the > PrintGCApplicationConcurrentTime output is then the > time since the last safepoint (not since the application > restarted after the last GC). > > So anyone know why the PrintGCApplicationConcurrentTime output > does not print for all safepoints? Should it only printout > when a VM operation is executed as it does now? > > If yes, should the spelling of > PrintGCApplicationConcurrentTime be changed to drop > the GC, PrintApplicationConcurrentTime. Similarly with > PrintGCApplicationStoppedTime -> PrintApplicationStoppedTime. > > Or should it printout for all safepoints? This is > simpler in that the printing could be added to > RuntimeService::record_safepoint_begin()) so > we would not miss new safepoints. But we might > be dumping useless information. > > Or I could hack the code so that information is only > printed around GC's. And maybe not printout some > useful information. > > From Paul.Hohensee at Sun.COM Wed Apr 15 10:16:40 2009 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Wed, 15 Apr 2009 13:16:40 -0400 Subject: Garbage Collection Pauses & Non-interruptable System Calls In-Reply-To: References: Message-ID: <49E61678.6000308@sun.com> A good page to read. Take a look at the Thread Management section too, esp. VM Operations and Safepoints. On x86/x64/sparc the polling scheme described there (thread asking 'should I block for a safepoint') works by issuing a read from a normally readable page called the 'polling page'. When the vm thread calls a safepoint, it sets the polling page protection to no access, which causes a thread issuing the read (we call the read a 'safepoint poll') to fault, trap and block. This scheme would work on Itanium as well, though one could also use a branch on one of the condition code bits instead of a load. Paul Mark R Maxey wrote: > > Here's is the URL I tried to include: > > http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Java%20Native%20Interface%20(JNI)|outline > > > > We are using the concurrent GC with a single generation. After we > workaround this immediate issue, we plan to migrate to multiple > generations and tweak the sizes of the generations. > > It is encouraging to hear that HotSpot uses a different algorithm. > I'll see what I can do to accellerate its usage. > > I'd like to understand HotSpot's behavior a little better. It sounds > like your algorithm can do the mark & sweep on a Java thread in native > code without pausing that thread? > > Thanks for all the feedback. I'll continue reading ... > > > Mark Maxey > Raytheon, Garland > 580/2/P22-1 > (972)205-5760 > Mark_R_Maxey at Raytheon.com > > > *Paul Hohensee * > Sent by: Paul.Hohensee at Sun.COM > > 04/14/2009 05:06 PM > > > To > Mark R Maxey > cc > "Y. Srinivas Ramakrishna" , > hotspot-gc-dev at openjdk.java.net, Andrew M Dungan > , David A Lilly > > Subject > Re: Garbage Collection Pauses & Non-interruptable System Calls > > > > > > > > > > The url for "Hotspot Runtime Overview of JNI" didn't come through for me. > > In any case, as Ramki noted, Hotspot lets native code called from Java > run free > during GC pauses, unless said native code calls back into the jvm for > some reason, > including just returning back to Java from native. Hotspot does _not_ > try to > pause threads executing native code, nor does Hotspot use signal > mechanisms > to block threads executing Java code so GC can happen. Hotspot uses a > polling > mechanism instead because signal delivery mechanisms on Unix and Linux are > unreliable. I doubt you'll be able to reproduce the JRockit issue with > Hotspot. > You might have other problems, but not that one. > > I suggest forwarding your questions to the JRockit team at Oracle. > Though I suspect > some of them are on this list too. :) > > Please try Hotspot before you give up on Java. From your description, > you should > use the CMS (concurrent mark-sweep) collector. See also the GC > performance info > accessible from > > http://java.sun.com/performance > > and Jon Masamitsu's blog > > http://blogs.sun.com/jonthecollector/ > > Paul > > Mark R Maxey wrote: > > > > After reading the last paragraph of HotSpot Runtime Overview of JNI > > more closely, I understand more. I think we're almost on the same > > page. The problem seems to be that all threads are suspended until > > the Java thread returns from the native call. > > > > > > Mark Maxey > > Raytheon, Garland > > 580/2/P22-1 > > (972)205-5760 > > Mark_R_Maxey at Raytheon.com > > > > > > *Mark R Maxey/US/Raytheon* > > > > 04/14/2009 12:37 PM > > > > > > To > > "Y. Srinivas Ramakrishna" > > cc > > hotspot-gc-dev at openjdk.java.net, > Y.S.Ramakrishna at Sun.COM, Andrew M > > Dungan/US/Raytheon at MAIL, David A Lilly/RCS/Raytheon/US at MAIL, Mark R > > Maxey/US/Raytheon at MAIL > > Subject > > Re: Garbage Collection Pauses & Non-interruptable > System CallsLink > > > > > > > > > > > > > > > > > > > > > > > > Thank you for your reply. The speed and depth of your response is > > encouraging. > > > > Let me confess something I should have done up-front. The behavior > > we're seeing is using JDK 5 via JRockit R27.6. We're in the process > > of reproducing these problems under HotSpot JDK 6 Update 12, though > > it'll be a few days before we can do so. The reason I'm pinging this > > forum is to research in advance what differences we might expect > > between the two JVMs. > > > > Let me describe exactly what we're seeing as provided by doing an > > strace on the process: > > > > 1. A Java thread calls a native C code that ultimately calls a > > pwrite(). We suspect that the device driver ultimately makes a > > non-interruptable system call to transfer the data directly from > > our mem-aligned 128 MB buffer to disk. > > 2. The GC thread sends a tgkill(SIGUSR1) to all threads > > 3. The GC thread waits on mutex #1 (presumably waiting on all the > > threads to signal it that it can begin GC) > > 4. The Java thread wakes mutex #1 (presumably signaling the GC it > > is ready to go) > > 5. The Java thread waits on mutex #2 (presumably waiting on GC to > > finish) > > 6. The GC thread wakes mutex #2 (presumably telling the Java thread > > it can resume processing) > > > > > > We're seeing times between #3 & #4 that are proportional to the amount > > of time spent in the pwrite(). We also see some overhead between #5 > >  that is proportional to the number of Java threads we have > > (currently between 30 & 40 that we've created not counting the JVMs). > > > > Unfortunately, the JRockit logging only reveals the actual time GC > > takes (#4 - #5). Hopefully, HotSpot's logging includes the total time > > (#2 - #6). > > > > I'm pursuing these questions with Oracle/BEA. Again, I'm just trying > > get a feel for HotSpot's behavior in comparison. While we're using > > JRockit today, HotSpot will be our ultimate platform. > > > > > > One alternate solution that has been suggested is infrequently calling > > GC explicitly within our code during special times when we know we can > > afford to take the hit. We would even accept a greater hit than > > normal if we could avoid being impacted during critical times. > > Everything I've ever read says to not do this, but I'm curious why in > > this case this is a bad idea. Note that we're using the concurrent > > GC, so I'm not even sure if System.gc() supports this. > > > > > > Thanks again! > > > > > > Mark Maxey > > Raytheon, Garland > > 580/2/P22-1 > > (972)205-5760 > > Mark_R_Maxey at Raytheon.com > > > > > > *"Y. Srinivas Ramakrishna" * > > Sent by: Y.S.Ramakrishna at Sun.COM > > > > 04/14/2009 10:19 AM > > > > > > To > > Mark R Maxey > > cc > > hotspot-gc-dev at openjdk.java.net > > Subject > > Re: Garbage Collection Pauses & Non-interruptable > System Calls > > > > > > > > > > > > > > > > > > > > Hello Mark -- > > > > I am assuming your threads doing DMA are actually executing native > > code (or > > waiting for signals in native code). Threads in native code do not > > need to > > synchronize \in any manner with GC while they are executing native code. > > It is only the transitions to and from native mode (from Java code) that > > require > > synchronization. Roughly speaking, the JVM fences off those native > > threads so that, in the event that they need to re-enter the JVM or > > access the Java heap, they will be suspended until a GC/safepoint that > > is in progress is completed. > > > > Thus, I do not believe you need to fear that a long-running DMA call > would > > cause GC's to be delayed (which I understand is your main concern > below). > > > > Have you actually seen cases where this is happening? If so, what > > version of the JDK > > are you running? > > > > thanks. > > -- ramki > > > > Mark R Maxey wrote: > > > Hello, > > > > > > I have a problem I was hoping with which I need some advice. > > > > > > We wrote a custom JNI library for file I/O that sits underneath the > > Java > > > NIO FileChannel. One of our driving requirements is highly performant > > > file I/O. We achieved this by doing DMA I/O from large direct memory > > > aligned buffers. The JNI is very trivial - it just takes a buffer and > > > performs the appropriate system call based on the parameters given > > to it. > > > 100% of the logic for calculating offsets, buffer management, etc. > > is all > > > in our implementation of java.nio.FileChannel. > > > > > > Here's our problem: We have requirements to respond to some > > messages in > > > as little as 250 ms. During this time, we're doing file writes of > > 128 MB > > > that take around 200 ms. When GC kicks in, it tries to pause all > > threads. > > > Because the DMA write is non-interruptable, GC waits for the I/O to > > > complete before being able to pause the thread & run. That means > > that GC > > > can take well over 200 ms putting us in grave danger of missing our > > > timelines. Worse, there is always the chance the write will hang > > due to a > > > bad filesystem. We've seen this cause the JVM to hang indefinitely > > > forcing us to cycle the process. > > > > > > Unless we find a solution that allows GC to continue while doing > > this I/O, > > > we will convert all the code to C++. While that might solve our > > timeline > > > for that particular process, we have many less performance critical > > > processes that use our JNI FileChannel libraries that would hang if a > > > filesystem goes bad. > > > > > > We've tweaked the file system device timeouts down to a minimum, but > > they > > > are still very high (on the order of several seconds to minutes). It > > > would be nice if the JVM had a similar timeout for pausing threads, > > i.e., > > > where the pause times out after X number of milliseconds. We'd be > > willing > > > to sacrifice a larger heap size and postpone GC in the hopes that > > the next > > > time it ran GC, we wouldn't be in the middle of a non-interruptable > > system > > > call. > > > > > > The only solution being batted around here is pushing the system > > calls out > > > of Java threads and into native threads. The JNI call would push > > the info > > > for the I/O call onto a native C++ queue where a small number of > native > > > threads (3?) would pull the data off the queue and perform the actual > > > system call. The trick is finding an implementation where the Java > > > thread blocked waiting on a response from the native thread is > > > interruptible. All this assumes GC doesn't try to pause native > > threads. > > > We thought about using pthreads, but were concerned about its signal > > > interaction with the JVM. So, we're leaning towards using pipes to > > push > > > data from one thread to another. > > > > > > If you have any suggestions or advice, we are desperate for your > wisdom. > > > > > > Thanks! > > > > > > > > > Mark Maxey > > > Raytheon, Garland > > > 580/2/P22-1 > > > (972)205-5760 > > > Mark_R_Maxey at Raytheon.com > > > > > > > > > > > > > > > > > > > From jed at atlassian.com Wed Apr 15 16:22:26 2009 From: jed at atlassian.com (Jed Wesley-Smith) Date: Thu, 16 Apr 2009 09:22:26 +1000 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E5F466.5020600@sun.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> Message-ID: Classes as well. We end up getting an OOME although the profilers report only a third of the heap is reachable. Although I indicated we saw this on the IBM jdk analysis of that dump showed a completely different issue that apparently may not be a problem (due to reflection optimisation on that jdk) - the dead objects appear to have been correctly cleared. We are reproducing this to verify. Additionally we tried running with -client on the sun jvms as we saw a bug that might have caused it reported against server only but without success. cheers, jed. On 16/04/2009, at 12:51 AM, Tony Printezis wrote: > OK, I'll bite. > > When you say: "a large section of memory (a plugin framework)" do > you mean only objects in the young / old gen, or also classes in the > perm gen? > > How do you know that said memory is not being reclaimed? Do you > eventually get an OOM? > > Given that it happens with two different JVMs (I assume you use > HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to > be a GC bug, as both JVMs would need to have the same bug. Not > impossible, but unlikely, IMHO. > > Tony > > Jed Wesley-Smith wrote: >> all, >> >> I am writing to this list in some desperation hoping for some >> expert advice. We (the JIRA development team at Atlassian) have >> been hunting memory leaks for some weeks and in the process have >> tracked down and removed every possible reference to a large >> section of memory (a plugin framework) that we could find. Starting >> with all strong references and proceeding to remove soft and weak >> references - even things like clearing the java.lang.reflect.Proxy >> cache - and even Finalizer references until both YourKit, Eclipse >> MAT, JProfiler and jhat all report that the memory in question is >> dead and should be collectable, but inexplicably _the JVM still >> holds on to it_. There are no JNI Global references either, yet >> this memory remains uncollectable! >> >> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM >> 1.6 JDK on Linux. >> >> So my question is, how on earth do I search for what is referencing >> this uncollectable memory? Are there any other tools that can help >> find why this memory is not collected? Can I query the VM directly >> somehow? >> >> I fear this is a JVM GC bug as no known memory analysis tool can >> find the heap root (i.e. according to "the rules" there is no heap >> root). Are there any known GC memory leaks caused by ClassLoaders >> being dropped for instance? >> >> The application is creating and disposing of a lot of ClassLoaders >> via OSGi (Apache Felix) with Spring OSGi. It creates a lot of >> java.lang.reflect.Proxy class instances. >> >> We have written this up and added an example heap dump here: >> http://jira.atlassian.com/browse/JRA-16932 >> >> Having come to the end of our tethers here, if anyone can help in >> any way it would be massively appreciated. >> >> cheers, >> Jed Wesley-Smith >> JIRA Team @ Atlassian > > -- > --------------------------------------------------------------------- > | 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 Jon.Masamitsu at Sun.COM Thu Apr 16 06:48:29 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Thu, 16 Apr 2009 06:48:29 -0700 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E4D288.7070001@Sun.COM> References: <49E4D288.7070001@Sun.COM> Message-ID: <49E7372D.6000407@Sun.COM> Sentiment at this point seems to favor including the application times (stopped time and run time) for all the safepoints. We'll start on making that the fix. On 04/14/09 11:14, Jon Masamitsu wrote: > Question: Do users care about applications times output > for PrintGCApplicationConcurrentTime only relative to > GC's? > > > I have a CR > > 6782663: Data produced by PrintGCApplicationConcurrentTime and > PrintGCApplicationStoppedTime is not accurate > > where the complaint is that the application time as output > for PrintGCApplicationConcurrentTime does not match the time > as measured by the time between GC timestamps. Actually the > user is adding up all the times reported for > PrintGCApplicationConcurrentTime between the GC timestamps > and saying that that sum can be vastly off from the > time between GC timestamps. And the user is right. > > I think the problem is that the timers used to report > PrintGCApplicationConcurrentTime are updated more often > than the PrintGCApplicationConcurrentTime time is > reported. In VMThread::loop() in share/vm/runtime/vmThread.cpp > around line 425 the PrintGCApplicationConcurrentTime is > reported before the call to SafepointSynchronize::begin(). > Whereas near line 391 and near line 520 calls to > SafepointSynchronize::begin() do not report for > PrintGCApplicationConcurrentTime. The calls to > SafepointSynchronize::begin() will update the application > timer (_app_timer via a call to > RuntimeService::record_safepoint_begin()). Updating > resets the timer to the current time and the > PrintGCApplicationConcurrentTime output is then the > time since the last safepoint (not since the application > restarted after the last GC). > > So anyone know why the PrintGCApplicationConcurrentTime output > does not print for all safepoints? Should it only printout > when a VM operation is executed as it does now? > > If yes, should the spelling of > PrintGCApplicationConcurrentTime be changed to drop > the GC, PrintApplicationConcurrentTime. Similarly with > PrintGCApplicationStoppedTime -> PrintApplicationStoppedTime. > > Or should it printout for all safepoints? This is > simpler in that the printing could be added to > RuntimeService::record_safepoint_begin()) so > we would not miss new safepoints. But we might > be dumping useless information. > > Or I could hack the code so that information is only > printed around GC's. And maybe not printout some > useful information. > > From rainer.jung at kippdata.de Thu Apr 16 08:06:31 2009 From: rainer.jung at kippdata.de (Rainer Jung) Date: Thu, 16 Apr 2009 17:06:31 +0200 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E7372D.6000407@Sun.COM> References: <49E4D288.7070001@Sun.COM> <49E7372D.6000407@Sun.COM> Message-ID: <49E74977.9020600@kippdata.de> On 16.04.2009 15:48, Jon Masamitsu wrote: > Sentiment at this point seems to favor including > the application times (stopped time and run time) > for all the safepoints. We'll start on making that > the fix. I would also agree, but with the additional remark, that in case this increases the number of output lines (number of events per time that trigger a line) very much (like by a factor of 10), then it might be not that nice. If it would be allowed w.r.t. compatibility to include some keyword indicating the cause/type of the event on the same line, that would make it even more useful. GC could be one such event type. Regards, Rainer > On 04/14/09 11:14, Jon Masamitsu wrote: >> Question: Do users care about applications times output >> for PrintGCApplicationConcurrentTime only relative to >> GC's? >> >> >> I have a CR >> >> 6782663: Data produced by PrintGCApplicationConcurrentTime and >> PrintGCApplicationStoppedTime is not accurate >> >> where the complaint is that the application time as output >> for PrintGCApplicationConcurrentTime does not match the time >> as measured by the time between GC timestamps. Actually the >> user is adding up all the times reported for >> PrintGCApplicationConcurrentTime between the GC timestamps >> and saying that that sum can be vastly off from the >> time between GC timestamps. And the user is right. >> >> I think the problem is that the timers used to report >> PrintGCApplicationConcurrentTime are updated more often >> than the PrintGCApplicationConcurrentTime time is >> reported. In VMThread::loop() in share/vm/runtime/vmThread.cpp >> around line 425 the PrintGCApplicationConcurrentTime is >> reported before the call to SafepointSynchronize::begin(). >> Whereas near line 391 and near line 520 calls to >> SafepointSynchronize::begin() do not report for >> PrintGCApplicationConcurrentTime. The calls to >> SafepointSynchronize::begin() will update the application >> timer (_app_timer via a call to >> RuntimeService::record_safepoint_begin()). Updating >> resets the timer to the current time and the >> PrintGCApplicationConcurrentTime output is then the >> time since the last safepoint (not since the application >> restarted after the last GC). >> >> So anyone know why the PrintGCApplicationConcurrentTime output >> does not print for all safepoints? Should it only printout >> when a VM operation is executed as it does now? >> >> If yes, should the spelling of >> PrintGCApplicationConcurrentTime be changed to drop >> the GC, PrintApplicationConcurrentTime. Similarly with >> PrintGCApplicationStoppedTime -> PrintApplicationStoppedTime. >> >> Or should it printout for all safepoints? This is >> simpler in that the printing could be added to >> RuntimeService::record_safepoint_begin()) so >> we would not miss new safepoints. But we might >> be dumping useless information. >> >> Or I could hack the code so that information is only >> printed around GC's. And maybe not printout some >> useful information. From Jon.Masamitsu at Sun.COM Thu Apr 16 08:39:01 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Thu, 16 Apr 2009 08:39:01 -0700 Subject: PrintGCApplicationConcurrentTime / PrintGCApplicationStoppedTime In-Reply-To: <49E74977.9020600@kippdata.de> References: <49E4D288.7070001@Sun.COM> <49E7372D.6000407@Sun.COM> <49E74977.9020600@kippdata.de> Message-ID: <49E75115.4040005@Sun.COM> On 04/16/09 08:06, Rainer Jung wrote: > On 16.04.2009 15:48, Jon Masamitsu wrote: >> Sentiment at this point seems to favor including >> the application times (stopped time and run time) >> for all the safepoints. We'll start on making that >> the fix. > > I would also agree, but with the additional remark, that in case this > increases the number of output lines (number of events per time that > trigger a line) very much (like by a factor of 10), then it might be not > that nice. I don't think there will be an order of magnitude increase over what outputs today. In the experiments I did the most common application-stop/application-run lines had to do with GC and biased locking. The additional lines will be for periodic safepoints to do asynchronous VM operations (operations requested but not needed synchonously). Those are at most at 1 second intervals. If you have biased locking turned off and long periods between GC's, these safepoints for asynchronous VM operations could dominate but I think you will have to accept that cost to get the benefit. > > If it would be allowed w.r.t. compatibility to include some keyword > indicating the cause/type of the event on the same line, that would make > it even more useful. GC could be one such event type. The stop times due to GC and other VM operations are straight forward. The application run time between VM operations will take work and may be confusing. We're considering special casing GC since that's of common interest (i.e., adding up all the application run times between two GC's to print the total application run time between the those GC's). > > Regards, > > Rainer > >> On 04/14/09 11:14, Jon Masamitsu wrote: >>> Question: Do users care about applications times output >>> for PrintGCApplicationConcurrentTime only relative to >>> GC's? >>> >>> >>> I have a CR >>> >>> 6782663: Data produced by PrintGCApplicationConcurrentTime and >>> PrintGCApplicationStoppedTime is not accurate >>> >>> where the complaint is that the application time as output >>> for PrintGCApplicationConcurrentTime does not match the time >>> as measured by the time between GC timestamps. Actually the >>> user is adding up all the times reported for >>> PrintGCApplicationConcurrentTime between the GC timestamps >>> and saying that that sum can be vastly off from the >>> time between GC timestamps. And the user is right. >>> >>> I think the problem is that the timers used to report >>> PrintGCApplicationConcurrentTime are updated more often >>> than the PrintGCApplicationConcurrentTime time is >>> reported. In VMThread::loop() in share/vm/runtime/vmThread.cpp >>> around line 425 the PrintGCApplicationConcurrentTime is >>> reported before the call to SafepointSynchronize::begin(). >>> Whereas near line 391 and near line 520 calls to >>> SafepointSynchronize::begin() do not report for >>> PrintGCApplicationConcurrentTime. The calls to >>> SafepointSynchronize::begin() will update the application >>> timer (_app_timer via a call to >>> RuntimeService::record_safepoint_begin()). Updating >>> resets the timer to the current time and the >>> PrintGCApplicationConcurrentTime output is then the >>> time since the last safepoint (not since the application >>> restarted after the last GC). >>> >>> So anyone know why the PrintGCApplicationConcurrentTime output >>> does not print for all safepoints? Should it only printout >>> when a VM operation is executed as it does now? >>> >>> If yes, should the spelling of >>> PrintGCApplicationConcurrentTime be changed to drop >>> the GC, PrintApplicationConcurrentTime. Similarly with >>> PrintGCApplicationStoppedTime -> PrintApplicationStoppedTime. >>> >>> Or should it printout for all safepoints? This is >>> simpler in that the printing could be added to >>> RuntimeService::record_safepoint_begin()) so >>> we would not miss new safepoints. But we might >>> be dumping useless information. >>> >>> Or I could hack the code so that information is only >>> printed around GC's. And maybe not printout some >>> useful information. From john.coomes at sun.com Thu Apr 16 22:42:29 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Apr 2009 05:42:29 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b55 for changeset aea0ace7a1e4 Message-ID: <20090417054229.C32E8EE56@hg.openjdk.java.net> Changeset: ba12117a5e6c Author: xdono Date: 2009-04-16 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/ba12117a5e6c Added tag jdk7-b55 for changeset aea0ace7a1e4 ! .hgtags From john.coomes at sun.com Thu Apr 16 22:46:18 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Apr 2009 05:46:18 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b55 for changeset 7a869f16ba83 Message-ID: <20090417054620.568DCEE5F@hg.openjdk.java.net> Changeset: 553a664b807b Author: xdono Date: 2009-04-16 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/553a664b807b Added tag jdk7-b55 for changeset 7a869f16ba83 ! .hgtags From john.coomes at sun.com Thu Apr 16 22:53:38 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Apr 2009 05:53:38 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b55 for changeset 039945fba683 Message-ID: <20090417055340.9E079EE6C@hg.openjdk.java.net> Changeset: c197c6801271 Author: xdono Date: 2009-04-16 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/c197c6801271 Added tag jdk7-b55 for changeset 039945fba683 ! .hgtags From john.coomes at sun.com Thu Apr 16 22:57:12 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Apr 2009 05:57:12 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b55 for changeset e0eebd978b83 Message-ID: <20090417055714.F290CEE71@hg.openjdk.java.net> Changeset: 0f7fbf85f7a1 Author: xdono Date: 2009-04-16 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/0f7fbf85f7a1 Added tag jdk7-b55 for changeset e0eebd978b83 ! .hgtags From john.coomes at sun.com Thu Apr 16 23:04:30 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Apr 2009 06:04:30 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 78 new changesets Message-ID: <20090417062053.52A37EE90@hg.openjdk.java.net> Changeset: bccdcd761796 Author: alanb Date: 2009-03-24 14:03 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bccdcd761796 6819886: System.getProperty("os.name") reports Vista on Windows 7 Reviewed-by: sherman ! src/windows/native/java/lang/java_props_md.c Changeset: 4c3f752993a5 Author: alanb Date: 2009-03-24 14:05 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4c3f752993a5 6807702: Integer.valueOf cache should be configurable Reviewed-by: darcy ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/System.java + test/java/lang/Integer/ValueOf.java Changeset: 78063cf930e5 Author: alanb Date: 2009-03-24 14:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/78063cf930e5 6819689: File.lastModified can return bogus value for remote file accessed as it is being deleted [win] Reviewed-by: sherman Contributed-by: andreas.frischknecht at softwired-inc.com ! src/windows/native/java/io/WinNTFileSystem_md.c Changeset: 52bdf8cec41d Author: alanb Date: 2009-03-24 14:10 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/52bdf8cec41d 6621689: (dc spec) DatagramChannel.receive when channel is not bound is not specified Reviewed-by: sherman ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! test/java/nio/channels/DatagramChannel/NotBound.java Changeset: 644849201ca6 Author: dl Date: 2009-03-24 19:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/644849201ca6 6800572: Removing elements from views of NavigableMap implementations does not always work correctly. Summary: Replace use of new TreeSet with new KeySet Reviewed-by: martin ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! test/java/util/Collection/MOAT.java Changeset: 2dae30c4d687 Author: mchung Date: 2009-03-25 12:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2dae30c4d687 6819122: DefaultProxySelector should lazily initialize the Pattern object and the NonProxyInfo objects Summary: Move two static NonProxyInfo fields into NonProxyInfo class and instantiate Pattern object when needed Reviewed-by: jccollet ! src/share/classes/sun/net/spi/DefaultProxySelector.java Changeset: 5303aece2068 Author: dl Date: 2009-03-26 11:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5303aece2068 6801020: Concurrent Semaphore release may cause some require thread not signaled Summary: Introduce PROPAGATE waitStatus Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java + test/java/util/concurrent/Semaphore/RacingReleases.java Changeset: 4a685f3f3ba8 Author: dl Date: 2009-03-26 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4a685f3f3ba8 6822903: Reliability and documentation improvements for ReentrantReadWriteLock Summary: Make firstReader a Thread, not a long Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java Changeset: b752110df530 Author: weijun Date: 2009-03-27 11:05 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b752110df530 6802846: jarsigner needs enhanced cert validation(options) Reviewed-by: xuelei ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 7264cacbddaa Author: alanb Date: 2009-03-27 15:24 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7264cacbddaa 6693490: (se) select throws "File exists" IOException under load (lnx) Reviewed-by: sherman ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java + test/java/nio/channels/Selector/RegAfterPreClose.java Changeset: 9fa8b6276b31 Author: alanb Date: 2009-03-27 16:04 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9fa8b6276b31 6772303: (se) IOException: Invalid argument" thrown on a call to Selector.select(value) with -d64 Reviewed-by: sherman ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c Changeset: ff0a9e50f033 Author: alanb Date: 2009-03-30 19:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ff0a9e50f033 Merge Changeset: 85a91be56593 Author: mchung Date: 2009-03-31 23:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/85a91be56593 6819110: Lazily load Sun digest provider for jar verification Summary: Lazily call Providers.getSunProvider() instead of at static initializer Reviewed-by: mullan ! src/share/classes/sun/security/util/ManifestEntryVerifier.java Changeset: ee75d1fac0ca Author: weijun Date: 2009-04-03 11:36 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ee75d1fac0ca 6825352: support self-issued certificate in keytool Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/selfissued.sh Changeset: de80210c56a6 Author: sherman Date: 2009-04-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/de80210c56a6 4681995: Add support for large (> 4GB) zip/jar files Summary: The ZIP64 format support is added for > 4GB jar/zip files Reviewed-by: alanb, martin + src/share/classes/java/util/zip/ZipConstants64.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/java/util/zip/package.html ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/share/native/java/util/zip/zlib-1.1.3/zlib.h + test/java/util/zip/LargeZip.java ! test/java/util/zip/ZipFile/LargeZipFile.java Changeset: 030b29ccd0db Author: sherman Date: 2009-04-03 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/030b29ccd0db Merge Changeset: 17f50ed5fcab Author: tbell Date: 2009-04-03 10:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/17f50ed5fcab Merge Changeset: 267d1f8aa82a Author: alanb Date: 2009-04-02 11:13 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/267d1f8aa82a 6824135: (ch) test/java/nio/channels/AsyncCloseAndInterrupt.java fails (lnx) Reviewed-by: sherman ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 464727e3afb4 Author: alanb Date: 2009-04-02 11:19 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/464727e3afb4 6666739: (ref) ReferenceQueue.poll() doesn't scale well 6711667: (ref) Update SoftReference timestamp only if clock advances Summary: Forward port from 6u14; originally fixed by Tom Rodriguez in earlier update Reviewed-by: martin ! src/share/classes/java/lang/ref/ReferenceQueue.java ! src/share/classes/java/lang/ref/SoftReference.java Changeset: aed19719b1e9 Author: alanb Date: 2009-04-02 16:31 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/aed19719b1e9 6824141: test/java/rmi/activation/rmidViaInheritedChannel tests fail Reviewed-by: peterjones ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java Changeset: 4befa480d3c8 Author: alanb Date: 2009-04-02 19:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4befa480d3c8 6824477: (se) Selector.select fails with IOException: "Invalid argument" if maximum file descriptors is low Reviewed-by: sherman ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java + test/java/nio/channels/Selector/LotsOfUpdates.java + test/java/nio/channels/Selector/lots_of_updates.sh Changeset: e50a00095a53 Author: alanb Date: 2009-04-03 22:10 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e50a00095a53 6823609: (se) Selector.select hangs on Windows under load Reviewed-by: sherman ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/java/nio/channels/Selector/HelperSlowToDie.java Changeset: 93d1fbe001b8 Author: alanb Date: 2009-04-06 08:59 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/93d1fbe001b8 4890703: Support SDP (sol) Reviewed-by: michaelm ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/net/mapfile-vers ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java + src/solaris/classes/sun/net/NetHooks.java + src/solaris/classes/sun/net/spi/SdpProvider.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java + src/solaris/lib/sdp/sdp.conf.template + src/solaris/native/sun/net/spi/SdpProvider.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c + src/windows/classes/sun/net/NetHooks.java + test/sun/net/sdp/ProbeIB.java + test/sun/net/sdp/Sanity.java + test/sun/net/sdp/sanity.sh Changeset: d89688532509 Author: alanb Date: 2009-04-06 11:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d89688532509 Merge - make/jprt.config Changeset: 45ff1a9d4edb Author: valeriep Date: 2009-04-06 18:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/45ff1a9d4edb 4735126: (cl) ClassLoader.loadClass locks all instances in chain when delegating Summary: Added support for parallel-capable class loaders Reviewed-by: alanb ! make/java/java/mapfile-vers ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/sun/misc/Launcher.java ! src/share/native/java/lang/ClassLoader.c + test/java/lang/ClassLoader/deadlock/Alice.java + test/java/lang/ClassLoader/deadlock/Bob.java + test/java/lang/ClassLoader/deadlock/DelegatingLoader.java + test/java/lang/ClassLoader/deadlock/Starter.java + test/java/lang/ClassLoader/deadlock/SupAlice.java + test/java/lang/ClassLoader/deadlock/SupBob.java + test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh + test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh Changeset: 22b6e09960c1 Author: valeriep Date: 2009-04-06 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/22b6e09960c1 6440846: (cl) Deadlock between AppClassLoader and ExtClassLoader Summary: Fixed a deadlock between the two class loaders Reviewed-by: alanb ! src/share/classes/sun/security/jca/ProviderConfig.java + test/java/security/Security/ClassLoaderDeadlock/CreateSerialized.java + test/java/security/Security/ClassLoaderDeadlock/Deadlock2.java + test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh Changeset: 63e460d29580 Author: tbell Date: 2009-04-10 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/63e460d29580 Merge - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties Changeset: d0b6e69791c8 Author: art Date: 2009-02-11 17:07 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d0b6e69791c8 6633275: Need to support shaped/translucent windows Summary: forward-port from 6u14, no public API is introduced Reviewed-by: anthony, dcherepanov ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/xawt/mapfile-vers ! src/share/classes/com/sun/awt/AWTUtilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/native/sun/awt/utility/rect.c ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_p.h ! src/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java + src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/native/sun/awt/utility/rect.h ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_BitmapUtil.h ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java + test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java + test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form + test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java + test/com/sun/awt/Translucency/WindowOpacity.java + test/sun/java2d/pipe/RegionOps.java Changeset: d78988dd5659 Author: art Date: 2009-02-12 17:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d78988dd5659 6804680: Solaris AMD64 build fails after the fix for 6633275/7 Summary: addition to the fix for 6633275 Reviewed-by: yan ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 Changeset: 0d01d1f0954d Author: dcherepanov Date: 2009-02-12 18:24 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0d01d1f0954d 6724890: Deadlock between AWT-EventQueue-1 and AWT-XAWT threads during IDE start Reviewed-by: art, ant ! src/share/classes/java/awt/Frame.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h Changeset: 03276203c39c Author: art Date: 2009-02-17 10:42 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/03276203c39c 6806035: Fix for 6804680 is incomplete Reviewed-by: yan ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 Changeset: 5453a374c1d5 Author: dcherepanov Date: 2009-02-17 14:27 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5453a374c1d5 6769607: PIT : Modal frame hangs for a while for few seconds in 6u12 b01 pit build Reviewed-by: art, anthony ! src/share/classes/java/awt/Window.java ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h Changeset: 9cdba92883bf Author: dcherepanov Date: 2009-02-17 14:30 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9cdba92883bf 6792023: Print suspends on Windows 2000 Pro since 6u12 b01 Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: e03aa9d6b8d5 Author: dcherepanov Date: 2009-02-17 14:44 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e03aa9d6b8d5 6723941: Crash in sun.awt.windows.WToolkit.eventLoop() Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Frame.cpp Changeset: 2083f9461cea Author: dcherepanov Date: 2009-02-19 14:10 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2083f9461cea 6806224: PIT : Getting java.lang.NullPointerException while opening Filedialog Reviewed-by: art, dav ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java Changeset: 66d6db0a1de6 Author: anthony Date: 2009-02-20 17:34 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/66d6db0a1de6 6804747: Ensure consistent graphicsConfig member across components hierarchy Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Canvas.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/CanvasPeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/ComponentAccessor.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XPanelPeer.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/awt/awt_Component.h ! src/solaris/native/sun/awt/awt_Window.h ! src/solaris/native/sun/xawt/XToolkit.c ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/windows/WCanvasPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WPanelPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: b22974c82ca8 Author: lana Date: 2009-02-22 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b22974c82ca8 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! make/sun/awt/mapfile-mawt-vers ! make/sun/xawt/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java ! src/share/classes/javax/swing/RepaintManager.java - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java - src/share/lib/audio/soundbank.gm ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: a2082e850247 Author: anthony Date: 2009-03-03 13:54 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a2082e850247 6811674: Container.setComponentZOrder throws NPE Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: ae27b7949714 Author: dcherepanov Date: 2009-03-04 13:05 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ae27b7949714 6809227: poor performance on Panel.Add() method in jdk6 Reviewed-by: art, anthony ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Panel.cpp ! src/windows/native/sun/windows/awt_Panel.h Changeset: e7205c5dd3b7 Author: art Date: 2009-03-04 18:10 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e7205c5dd3b7 6784816: Remove AWT tree lock from Container methods: getComponent, getComponents, getComponentCount Reviewed-by: anthony, dav ! src/share/classes/java/awt/Container.java Changeset: 4dc625187820 Author: ant Date: 2009-03-10 18:33 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4dc625187820 6806217: implement synthetic focus model for MS Windows Reviewed-by: art, dcherepanov ! make/sun/awt/make.depend ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java + src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Button.h ! src/windows/native/sun/windows/awt_Canvas.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Checkbox.h ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_KeyboardFocusManager.cpp - src/windows/native/sun/windows/awt_KeyboardFocusManager.h ! src/windows/native/sun/windows/awt_List.cpp ! src/windows/native/sun/windows/awt_List.h ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_ScrollPane.h ! src/windows/native/sun/windows/awt_Scrollbar.cpp ! src/windows/native/sun/windows/awt_Scrollbar.h ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h ! src/windows/native/sun/windows/awtmsg.h + test/java/awt/Focus/ClearGlobalFocusOwnerTest/ClearGlobalFocusOwnerTest.java ! test/java/awt/Focus/IconifiedFrameFocusChangeTest/IconifiedFrameFocusChangeTest.java + test/java/awt/Focus/RemoveAfterRequest/RemoveAfterRequest.java Changeset: 04b368454df3 Author: ant Date: 2009-03-11 16:11 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/04b368454df3 6815946: regression: failed to build MToolkit Reviewed-by: anthony ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/motif/MToolkit.java Changeset: 6df5f5fb5174 Author: dcherepanov Date: 2009-03-13 18:07 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6df5f5fb5174 6805897: Gap present between the choice and its drop down list in Jdk 7 build for a non resizable frame. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java Changeset: c58f41b4bfbd Author: dcherepanov Date: 2009-03-20 08:41 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c58f41b4bfbd 6774258: api/java_awt/Component/index.html#PaintUpdate fails randomly Reviewed-by: art ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java + test/java/awt/Component/NoUpdateUponShow/NoUpdateUponShow.java Changeset: 55f02057dc37 Author: dcherepanov Date: 2009-03-23 11:59 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/55f02057dc37 6516404: regression: Choice vertical scrollbar is not seen when the item in the choice is increased more than Reviewed-by: art, dav ! src/windows/native/sun/windows/awt_Choice.cpp Changeset: adaee9531504 Author: dcherepanov Date: 2009-03-23 09:47 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/adaee9531504 6730447: Support for high resolution mouse wheel is still incomplete. AWT panel needs to be supported Reviewed-by: art, dav ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h + test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html + test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.java Changeset: f3ed90be28fc Author: rkennke Date: 2009-03-24 21:57 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f3ed90be28fc 6809233: Modal dialog blocks calling thread after it is hidden and disposed Summary: Send WakingRunnable to toolkit to prevent early cleanup. Reviewed-by: art, son ! src/share/classes/java/awt/Dialog.java Changeset: a702e8ff83bd Author: anthony Date: 2009-03-25 13:37 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a702e8ff83bd 6714678: IDE (Netbeans, Eclipse, JDeveloper) Debugger hangs process on Linux Summary: Added the system property sun.awt.disablegrab Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 0cbcc4bdf95a Author: anthony Date: 2009-03-26 14:38 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0cbcc4bdf95a 6693253: Security Warning appearance requires enhancements 6779717: A Window does not show applet security warning icon on X platforms 6785058: Parent dn't get the focus after dialog is closed if security warning is applied Summary: Forward-port from 6u10-6u14 Reviewed-by: art, dcherepanov ! make/sun/awt/Depend.mak ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/README ! make/sun/awt/make.depend ! make/sun/xawt/FILES_c_unix.gmk ! make/sun/xawt/Makefile ! make/sun/xawt/mapfile-vers + src/share/classes/com/sun/awt/SecurityWarning.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java + src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java + src/solaris/classes/sun/awt/X11/security-icon-bw16.png + src/solaris/classes/sun/awt/X11/security-icon-bw24.png + src/solaris/classes/sun/awt/X11/security-icon-bw32.png + src/solaris/classes/sun/awt/X11/security-icon-bw48.png + src/solaris/classes/sun/awt/X11/security-icon-interim16.png + src/solaris/classes/sun/awt/X11/security-icon-interim24.png + src/solaris/classes/sun/awt/X11/security-icon-interim32.png + src/solaris/classes/sun/awt/X11/security-icon-interim48.png + src/solaris/classes/sun/awt/X11/security-icon-yellow16.png + src/solaris/classes/sun/awt/X11/security-icon-yellow24.png + src/solaris/classes/sun/awt/X11/security-icon-yellow32.png + src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/solaris/native/sun/awt/utility/rect.h ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h + src/windows/native/sun/windows/DllUtil.cpp + src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/awt.rc ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + src/windows/native/sun/windows/security_warning.ico + src/windows/native/sun/windows/security_warning_bw.ico + src/windows/native/sun/windows/security_warning_int.ico + test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java + test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy + test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java Changeset: abf3b2ecfa06 Author: yan Date: 2009-03-27 12:01 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/abf3b2ecfa06 6680988: KeyEvent is still missing VK values for many keyboards Summary: 2 new methods and some fields added to KeyEvent, plus hash of constants introduced Reviewed-by: art ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/MenuShortcut.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/SwingUtilities.java + src/share/classes/sun/awt/ExtendedKeyCodes.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_KeyEvent.cpp ! src/windows/native/sun/windows/awt_KeyEvent.h + test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html + test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java Changeset: 9d26016be6fa Author: yan Date: 2009-03-30 16:33 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9d26016be6fa 6823589: Remake sizes.64-solaris-i386 with newly added fields 6782746: Keyboard hotkeys don't work in locales where non latin characters are used 6299348: Zero keycode returned in keyPressed and keyReleased for some keys in non-english layout - Win32 6316369: Provide a method to convert a character to VK_* Java keycode, if possible. 6446568: KeyEvent lacks 3 virtual keys of Danish keyboards 6559449: Support for converting from char to KeyEvent VK_ keycode 6182651: Need to identify any key pressed/released with a unique code Summary: Various by-products of 6680988 fix. Reviewed-by: art ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 Changeset: 3a9ae1117c12 Author: anthony Date: 2009-03-31 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3a9ae1117c12 6819601: Fix AWT JTReg tests which fail to compile Summary: Fix compilation of tests. Reviewed-by: anthony, son Contributed-by: Andrew John Hughes ! test/java/awt/Component/isLightweightCrash/StubPeerCrash.java ! test/java/awt/EventQueue/6638195/bug6638195.java Changeset: 1cb2e3e0631f Author: anthony Date: 2009-04-01 19:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1cb2e3e0631f 6818312: com.sun.awt.SecurityWarning.getSize() always reports (0, 0) on X11 Summary: The fix got pushed with 6693253. However the test was omitted. Here it comes. Reviewed-by: dcherepanov, art + test/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java Changeset: c5f1721eebb2 Author: lana Date: 2009-04-09 13:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c5f1721eebb2 Merge ! make/sun/awt/Makefile ! make/sun/xawt/mapfile-vers ! src/windows/native/sun/windows/awt.rc - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 73f0e751b669 Author: dcherepanov Date: 2009-04-13 15:22 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/73f0e751b669 6829326: Getting java.lang.NullPointerException: null pData while opening a File,Print,Page Dialog in Win Reviewed-by: art, yan ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java Changeset: 6a789813407d Author: lana Date: 2009-04-13 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6a789813407d Merge Changeset: a5746eca3686 Author: lana Date: 2009-04-13 22:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a5746eca3686 Merge - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 442b563e57c6 Author: peterz Date: 2009-02-04 18:48 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/442b563e57c6 6588003: LayoutQueue shares mutable implementation across AppContexts Summary: DefaultQueue property is made per-AppContext Reviewed-by: alexp ! src/share/classes/javax/swing/text/LayoutQueue.java + test/javax/swing/text/LayoutQueue/Test6588003.java Changeset: 62a84e564a8c Author: malenkov Date: 2009-02-05 14:48 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/62a84e564a8c 4769844: classes in java.beans that are serializable but don't define serialVersionUID Reviewed-by: peterz, rupashka ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/IntrospectionException.java ! src/share/classes/java/beans/PropertyChangeEvent.java ! src/share/classes/java/beans/PropertyVetoException.java ! src/share/classes/java/beans/beancontext/BeanContextEvent.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java ! src/share/classes/java/beans/beancontext/BeanContextServiceAvailableEvent.java ! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedEvent.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/sun/beans/editors/ColorEditor.java ! src/share/classes/sun/beans/editors/FontEditor.java Changeset: 27dabbdfdcac Author: malenkov Date: 2009-02-05 17:00 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/27dabbdfdcac 6669869: Beans.isDesignTime() and other queries should be per-AppContext Reviewed-by: peterz, rupashka ! src/share/classes/java/beans/Beans.java + test/java/beans/Beans/6669869/TestDesignTime.java + test/java/beans/Beans/6669869/TestGuiAvailable.java Changeset: 0960e96d0de8 Author: peterz Date: 2009-02-05 19:16 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0960e96d0de8 6801769: 6588003 should be backed out from jdk7 Reviewed-by: alexp ! src/share/classes/javax/swing/text/LayoutQueue.java Changeset: 794e786306c1 Author: art Date: 2009-02-12 14:19 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/794e786306c1 6799345: JFC demos threw exception in the Java Console when applets are closed Reviewed-by: alexp, peterz ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/TimerQueue.java + test/javax/swing/system/6799345/TestShutdown.java Changeset: 6b77fbb7e33e Author: lana Date: 2009-02-23 11:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6b77fbb7e33e Merge - src/share/classes/com/sun/jmx/namespace/JMXNamespaceUtils.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/text/LayoutQueue.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: c466ef3f1ea0 Author: peterz Date: 2009-02-24 19:17 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c466ef3f1ea0 6804221: Three tests for JTabbedPane produce VM crash on rhel3 Reviewed-by: stayer, campbell ! src/solaris/native/sun/awt/gtk2_interface.c Changeset: 02b64d5fad60 Author: rupashka Date: 2009-02-26 11:44 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/02b64d5fad60 6794831: Infinite loop while painting ticks on Slider with maximum=MAX_INT Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6794831/bug6794831.java Changeset: 51148b9aed43 Author: rupashka Date: 2009-03-12 14:00 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/51148b9aed43 6491795: COM should be initialized for Shell API calls in ShellFolder2.cpp Reviewed-by: peterz, loneid ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/swing/FilePane.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/native/sun/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/6570445/bug6570445.java Changeset: 4f7dd74de2e3 Author: peterz Date: 2009-03-13 19:25 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4f7dd74de2e3 6815767: Bad parameter when calling another method in the class SynthTabbedPaneUI Reviewed-by: alexp, rupashka ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java Changeset: 540c7f47aadf Author: rupashka Date: 2009-03-17 16:06 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/540c7f47aadf 6738668: JFileChooser cannot be created under SecurityManager Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java + test/javax/swing/JFileChooser/6738668/bug6738668.java + test/javax/swing/JFileChooser/6738668/security.policy Changeset: 4bf886c9df34 Author: peterz Date: 2009-03-23 14:09 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4bf886c9df34 6653395: Default LAF is set to CrossPlatformLookAndFeel not SystemLookAndFeel Summary: Swing now checks AppContext properties to determine default LAF name. This is needed for plugin to be able to set default LAF w/o loading Swing classes. Reviewed-by: alexp, loneid ! src/share/classes/javax/swing/UIManager.java Changeset: 652e05578a7e Author: peterz Date: 2009-03-23 16:41 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/652e05578a7e 4783068: Components with HTML text should gray out the text when disabled Summary: Views fixed to use different colors when container is disabled Reviewed-by: gsm, rupashka ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java + test/javax/swing/text/html/Test4783068.java Changeset: b8d8ec2dac68 Author: rupashka Date: 2009-03-26 11:04 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/b8d8ec2dac68 6798062: Memory Leak on using getFiles of FileSystemView Reviewed-by: peterz, malenkov ! src/windows/native/sun/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/6798062/bug6798062.html + test/javax/swing/JFileChooser/6798062/bug6798062.java Changeset: ce3262ac93fa Author: peterz Date: 2009-04-06 13:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ce3262ac93fa 6635110: GTK problem when testing Sun Studio IDE on snv_77 with jdk1.6 using Gnome window manager Summary: GTKIconFactory icons should protect against null context passed in Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java + test/com/sun/java/swing/plaf/gtk/Test6635110.java Changeset: be3afc0e5775 Author: peterz Date: 2009-04-07 12:40 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/be3afc0e5775 6740974: api/javax_swing/PopupFactory/index.html#Ctor[PopupFactory2002] fails with NPE Reviewed-by: malenkov ! src/share/classes/javax/swing/PopupFactory.java Changeset: 1729e34a0287 Author: peytoia Date: 2009-04-10 11:51 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1729e34a0287 6404304: RFE: Unicode 5.1 support Reviewed-by: okutsu, naoto ! make/java/text/FILES_java.gmk ! make/java/text/Makefile ! make/tools/GenerateCharacter/CharacterData00.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt + make/tools/UnicodeData/VERSION ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/String.java ! src/share/classes/sun/text/normalizer/CharTrie.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerDataReader.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/Trie.java ! src/share/classes/sun/text/normalizer/TrieIterator.java + src/share/classes/sun/text/normalizer/UBiDiProps.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/classes/sun/text/normalizer/UCharacterProperty.java ! src/share/classes/sun/text/normalizer/UCharacterPropertyReader.java - src/share/classes/sun/text/normalizer/UProperty.java ! src/share/classes/sun/text/normalizer/UTF16.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/Utility.java ! src/share/classes/sun/text/normalizer/VersionInfo.java + src/share/classes/sun/text/resources/ubidi.icu ! src/share/classes/sun/text/resources/unorm.icu ! src/share/classes/sun/text/resources/uprops.icu ! test/java/lang/String/ToLowerCase.java Changeset: a54c407c4da3 Author: lana Date: 2009-04-09 20:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a54c407c4da3 Merge - src/share/classes/sun/text/normalizer/UProperty.java Changeset: 2cdf54e6e74c Author: lana Date: 2009-04-14 00:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2cdf54e6e74c Merge - src/share/classes/sun/text/normalizer/UProperty.java Changeset: 522bb5aa17e0 Author: lana Date: 2009-04-14 04:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/522bb5aa17e0 Merge - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 65095f13b7c4 Author: xdono Date: 2009-04-16 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/65095f13b7c4 Added tag jdk7-b55 for changeset 522bb5aa17e0 ! .hgtags From john.coomes at sun.com Thu Apr 16 23:33:14 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 17 Apr 2009 06:33:14 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 12 new changesets Message-ID: <20090417063335.DE61AEEA7@hg.openjdk.java.net> Changeset: 5caa6c45936a Author: mcimadamore Date: 2009-03-25 10:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/5caa6c45936a 6182950: methods clash algorithm should not depend on return type Summary: fixed code that checks for duplicate method declarations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + 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/6182950/T6182950c.java Changeset: 6ce39250fa88 Author: mcimadamore Date: 2009-03-25 10:28 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/6ce39250fa88 6816548: Uninitialized register when performing casting + auto(un)boxing Summary: Constant value of final variable is lost during lowering Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/boxing/T6816548.java Changeset: 1ee128971f5d Author: mcimadamore Date: 2009-03-25 10:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/1ee128971f5d 6400189: raw types and inference Summary: Fixed resolution problem with raw overriding (CCC) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + 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/OverrideChecks/6400189/T6400189c.java + test/tools/javac/OverrideChecks/6400189/T6400189d.java Changeset: 07da2ffbb76b Author: jjg Date: 2009-03-30 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/07da2ffbb76b 6819246: improve support for decoding instructions in classfile library Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/Code_attribute.java + src/share/classes/com/sun/tools/classfile/Instruction.java - src/share/classes/com/sun/tools/classfile/OpCodes.java + src/share/classes/com/sun/tools/classfile/Opcode.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java Changeset: 89f67512b635 Author: jjg Date: 2009-03-31 11:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/89f67512b635 6817950: refactor ClassReader to improve attribute handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: af10262bd031 Author: jjg Date: 2009-03-31 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/af10262bd031 6813059: replace use of JavaCompiler.errorCount with shouldContinue Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/policy/test3/A.java + test/tools/javac/policy/test3/Test.java Changeset: 3e4038edfcb7 Author: tbell Date: 2009-04-03 10:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/3e4038edfcb7 Merge - src/share/classes/com/sun/tools/classfile/OpCodes.java Changeset: 143956db282e Author: tbell Date: 2009-04-10 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/143956db282e Merge Changeset: 247468a1454b Author: dcherepanov Date: 2009-04-07 10:27 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/247468a1454b 6663040: Using com.sun.awt.AWTUtilities do not give warning while compilation Reviewed-by: yan, anthony ! src/share/classes/com/sun/tools/javac/resources/legacy.properties Changeset: 45be79d8d317 Author: lana Date: 2009-04-09 13:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/45be79d8d317 Merge Changeset: 7394a8694ced Author: lana Date: 2009-04-13 22:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/7394a8694ced Merge Changeset: 825f23a4f262 Author: xdono Date: 2009-04-16 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/825f23a4f262 Added tag jdk7-b55 for changeset 7394a8694ced ! .hgtags From kirk at kodewerk.com Fri Apr 17 10:51:28 2009 From: kirk at kodewerk.com (kirk) Date: Fri, 17 Apr 2009 19:51:28 +0200 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> Message-ID: <49E8C1A0.70904@kodewerk.com> Hi Jed, I've had a quick look at the heap dump. I'm having a little trouble understanding what is in there. What I can see is a large number of java.lang.reflect.Method objects being held. There seems to be two competing patterns of references holding onto these objects. I've attached some screenshots rather than use words. The scary thing is that the references include ClassLoader.scl, JDK12Hooks.systemClassLoader as well as Apache commons logging LogFactory. With this type of the complex entanglement it would seem unlikely that these objects would ever be collected. The other pattern also includes the spiders web of references. It also includes UberspecImpl and a whole bunch of static collections. IME, static collections are involved in the vast majority of leaks I've diagnosed. Interestingly enough the a portion of the 2nd largest consumer of memory is also tangled up in the JDK12Hooks. Random sampling leads me to AST parse trees and "no reference". Looks like much of this is tied up with Velocity. In fact the largest consumer of memory at 24% is char[]. I'm failing to find anything that is not tied up with Velocity (AST parsing). Needs more investigation. Be interesting to run a test with generations turned on. NetBeans generations is a true count unlike that provided by YourKit. Regards, Kirk Jed Wesley-Smith wrote: > Classes as well. We end up getting an OOME although the profilers > report only a third of the heap is reachable. > > Although I indicated we saw this on the IBM jdk analysis of that dump > showed a completely different issue that apparently may not be a > problem (due to reflection optimisation on that jdk) - the dead > objects appear to have been correctly cleared. We are reproducing this > to verify. > > Additionally we tried running with -client on the sun jvms as we saw a > bug that might have caused it reported against server only but without > success. > > cheers, > jed. > > On 16/04/2009, at 12:51 AM, Tony Printezis > wrote: > >> OK, I'll bite. >> >> When you say: "a large section of memory (a plugin framework)" do you >> mean only objects in the young / old gen, or also classes in the perm >> gen? >> >> How do you know that said memory is not being reclaimed? Do you >> eventually get an OOM? >> >> Given that it happens with two different JVMs (I assume you use >> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to >> be a GC bug, as both JVMs would need to have the same bug. Not >> impossible, but unlikely, IMHO. >> >> Tony >> >> Jed Wesley-Smith wrote: >>> all, >>> >>> I am writing to this list in some desperation hoping for some expert >>> advice. We (the JIRA development team at Atlassian) have been >>> hunting memory leaks for some weeks and in the process have tracked >>> down and removed every possible reference to a large section of >>> memory (a plugin framework) that we could find. Starting with all >>> strong references and proceeding to remove soft and weak references >>> - even things like clearing the java.lang.reflect.Proxy cache - and >>> even Finalizer references until both YourKit, Eclipse MAT, JProfiler >>> and jhat all report that the memory in question is dead and should >>> be collectable, but inexplicably _the JVM still holds on to it_. >>> There are no JNI Global references either, yet this memory remains >>> uncollectable! >>> >>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM >>> 1.6 JDK on Linux. >>> >>> So my question is, how on earth do I search for what is referencing >>> this uncollectable memory? Are there any other tools that can help >>> find why this memory is not collected? Can I query the VM directly >>> somehow? >>> >>> I fear this is a JVM GC bug as no known memory analysis tool can >>> find the heap root (i.e. according to "the rules" there is no heap >>> root). Are there any known GC memory leaks caused by ClassLoaders >>> being dropped for instance? >>> >>> The application is creating and disposing of a lot of ClassLoaders >>> via OSGi (Apache Felix) with Spring OSGi. It creates a lot of >>> java.lang.reflect.Proxy class instances. >>> >>> We have written this up and added an example heap dump here: >>> http://jira.atlassian.com/browse/JRA-16932 >>> >>> Having come to the end of our tethers here, if anyone can help in >>> any way it would be massively appreciated. >>> >>> cheers, >>> Jed Wesley-Smith >>> JIRA Team @ Atlassian >> >> -- >> --------------------------------------------------------------------- >> | 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 Antonios.Printezis at sun.com Fri Apr 17 11:22:34 2009 From: Antonios.Printezis at sun.com (Tony Printezis) Date: Fri, 17 Apr 2009 14:22:34 -0400 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E8C1A0.70904@kodewerk.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> Message-ID: <49E8C8EA.2000603@sun.com> Well, I was going to pointer the finger towards the class loaders... but Kirk here did a much more thorough analysis! :-) Tony kirk wrote: > Hi Jed, > > I've had a quick look at the heap dump. I'm having a little trouble > understanding what is in there. What I can see is a large number of > java.lang.reflect.Method objects being held. There seems to be two > competing patterns of references holding onto these objects. I've > attached some screenshots rather than use words. > > The scary thing is that the references include ClassLoader.scl, > JDK12Hooks.systemClassLoader as well as Apache commons logging > LogFactory. With this type of the complex entanglement it would seem > unlikely that these objects would ever be collected. The other pattern > also includes the spiders web of references. It also includes > UberspecImpl and a whole bunch of static collections. IME, static > collections are involved in the vast majority of leaks I've diagnosed. > > Interestingly enough the a portion of the 2nd largest consumer of > memory is also tangled up in the JDK12Hooks. Random sampling leads me > to AST parse trees and "no reference". Looks like much of this is tied > up with Velocity. In fact the largest consumer of memory at 24% is > char[]. I'm failing to find anything that is not tied up with Velocity > (AST parsing). > > Needs more investigation. Be interesting to run a test with > generations turned on. NetBeans generations is a true count unlike > that provided by YourKit. > > Regards, > Kirk > > > Jed Wesley-Smith wrote: >> Classes as well. We end up getting an OOME although the profilers >> report only a third of the heap is reachable. >> >> Although I indicated we saw this on the IBM jdk analysis of that dump >> showed a completely different issue that apparently may not be a >> problem (due to reflection optimisation on that jdk) - the dead >> objects appear to have been correctly cleared. We are reproducing >> this to verify. >> >> Additionally we tried running with -client on the sun jvms as we saw >> a bug that might have caused it reported against server only but >> without success. >> >> cheers, >> jed. >> >> On 16/04/2009, at 12:51 AM, Tony Printezis >> wrote: >> >>> OK, I'll bite. >>> >>> When you say: "a large section of memory (a plugin framework)" do >>> you mean only objects in the young / old gen, or also classes in the >>> perm gen? >>> >>> How do you know that said memory is not being reclaimed? Do you >>> eventually get an OOM? >>> >>> Given that it happens with two different JVMs (I assume you use >>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to >>> be a GC bug, as both JVMs would need to have the same bug. Not >>> impossible, but unlikely, IMHO. >>> >>> Tony >>> >>> Jed Wesley-Smith wrote: >>>> all, >>>> >>>> I am writing to this list in some desperation hoping for some >>>> expert advice. We (the JIRA development team at Atlassian) have >>>> been hunting memory leaks for some weeks and in the process have >>>> tracked down and removed every possible reference to a large >>>> section of memory (a plugin framework) that we could find. Starting >>>> with all strong references and proceeding to remove soft and weak >>>> references - even things like clearing the java.lang.reflect.Proxy >>>> cache - and even Finalizer references until both YourKit, Eclipse >>>> MAT, JProfiler and jhat all report that the memory in question is >>>> dead and should be collectable, but inexplicably _the JVM still >>>> holds on to it_. There are no JNI Global references either, yet >>>> this memory remains uncollectable! >>>> >>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM >>>> 1.6 JDK on Linux. >>>> >>>> So my question is, how on earth do I search for what is referencing >>>> this uncollectable memory? Are there any other tools that can help >>>> find why this memory is not collected? Can I query the VM directly >>>> somehow? >>>> >>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>> find the heap root (i.e. according to "the rules" there is no heap >>>> root). Are there any known GC memory leaks caused by ClassLoaders >>>> being dropped for instance? >>>> >>>> The application is creating and disposing of a lot of ClassLoaders >>>> via OSGi (Apache Felix) with Spring OSGi. It creates a lot of >>>> java.lang.reflect.Proxy class instances. >>>> >>>> We have written this up and added an example heap dump here: >>>> http://jira.atlassian.com/browse/JRA-16932 >>>> >>>> Having come to the end of our tethers here, if anyone can help in >>>> any way it would be massively appreciated. >>>> >>>> cheers, >>>> Jed Wesley-Smith >>>> JIRA Team @ Atlassian >>> >>> -- >>> --------------------------------------------------------------------- >>> | 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 kirk at kodewerk.com Fri Apr 17 12:07:12 2009 From: kirk at kodewerk.com (kirk) Date: Fri, 17 Apr 2009 21:07:12 +0200 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E8C8EA.2000603@sun.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> <49E8C8EA.2000603@sun.com> Message-ID: <49E8D360.9000507@kodewerk.com> forgot to attach. Regards, Kirk Tony Printezis wrote: > Well, I was going to pointer the finger towards the class loaders... > but Kirk here did a much more thorough analysis! :-) > > Tony > > kirk wrote: >> Hi Jed, >> >> I've had a quick look at the heap dump. I'm having a little trouble >> understanding what is in there. What I can see is a large number of >> java.lang.reflect.Method objects being held. There seems to be two >> competing patterns of references holding onto these objects. I've >> attached some screenshots rather than use words. >> >> The scary thing is that the references include ClassLoader.scl, >> JDK12Hooks.systemClassLoader as well as Apache commons logging >> LogFactory. With this type of the complex entanglement it would seem >> unlikely that these objects would ever be collected. The other >> pattern also includes the spiders web of references. It also includes >> UberspecImpl and a whole bunch of static collections. IME, static >> collections are involved in the vast majority of leaks I've diagnosed. >> >> Interestingly enough the a portion of the 2nd largest consumer of >> memory is also tangled up in the JDK12Hooks. Random sampling leads me >> to AST parse trees and "no reference". Looks like much of this is >> tied up with Velocity. In fact the largest consumer of memory at 24% >> is char[]. I'm failing to find anything that is not tied up with >> Velocity (AST parsing). >> >> Needs more investigation. Be interesting to run a test with >> generations turned on. NetBeans generations is a true count unlike >> that provided by YourKit. >> >> Regards, >> Kirk >> >> >> Jed Wesley-Smith wrote: >>> Classes as well. We end up getting an OOME although the profilers >>> report only a third of the heap is reachable. >>> >>> Although I indicated we saw this on the IBM jdk analysis of that >>> dump showed a completely different issue that apparently may not be >>> a problem (due to reflection optimisation on that jdk) - the dead >>> objects appear to have been correctly cleared. We are reproducing >>> this to verify. >>> >>> Additionally we tried running with -client on the sun jvms as we saw >>> a bug that might have caused it reported against server only but >>> without success. >>> >>> cheers, >>> jed. >>> >>> On 16/04/2009, at 12:51 AM, Tony Printezis >>> wrote: >>> >>>> OK, I'll bite. >>>> >>>> When you say: "a large section of memory (a plugin framework)" do >>>> you mean only objects in the young / old gen, or also classes in >>>> the perm gen? >>>> >>>> How do you know that said memory is not being reclaimed? Do you >>>> eventually get an OOM? >>>> >>>> Given that it happens with two different JVMs (I assume you use >>>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to >>>> be a GC bug, as both JVMs would need to have the same bug. Not >>>> impossible, but unlikely, IMHO. >>>> >>>> Tony >>>> >>>> Jed Wesley-Smith wrote: >>>>> all, >>>>> >>>>> I am writing to this list in some desperation hoping for some >>>>> expert advice. We (the JIRA development team at Atlassian) have >>>>> been hunting memory leaks for some weeks and in the process have >>>>> tracked down and removed every possible reference to a large >>>>> section of memory (a plugin framework) that we could find. >>>>> Starting with all strong references and proceeding to remove soft >>>>> and weak references - even things like clearing the >>>>> java.lang.reflect.Proxy cache - and even Finalizer references >>>>> until both YourKit, Eclipse MAT, JProfiler and jhat all report >>>>> that the memory in question is dead and should be collectable, but >>>>> inexplicably _the JVM still holds on to it_. There are no JNI >>>>> Global references either, yet this memory remains uncollectable! >>>>> >>>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the >>>>> IBM 1.6 JDK on Linux. >>>>> >>>>> So my question is, how on earth do I search for what is >>>>> referencing this uncollectable memory? Are there any other tools >>>>> that can help find why this memory is not collected? Can I query >>>>> the VM directly somehow? >>>>> >>>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>>> find the heap root (i.e. according to "the rules" there is no heap >>>>> root). Are there any known GC memory leaks caused by ClassLoaders >>>>> being dropped for instance? >>>>> >>>>> The application is creating and disposing of a lot of ClassLoaders >>>>> via OSGi (Apache Felix) with Spring OSGi. It creates a lot of >>>>> java.lang.reflect.Proxy class instances. >>>>> >>>>> We have written this up and added an example heap dump here: >>>>> http://jira.atlassian.com/browse/JRA-16932 >>>>> >>>>> Having come to the end of our tethers here, if anyone can help in >>>>> any way it would be massively appreciated. >>>>> >>>>> cheers, >>>>> Jed Wesley-Smith >>>>> JIRA Team @ Atlassian >>>> >>>> -- >>>> --------------------------------------------------------------------- >>>> | 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) >>>> >>>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3(2).png Type: image/png Size: 239027 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090417/65361260/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4(2).png Type: image/png Size: 216843 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090417/65361260/attachment-0001.png From jed at atlassian.com Fri Apr 17 16:32:25 2009 From: jed at atlassian.com (Jed Wesley-Smith) Date: Sat, 18 Apr 2009 09:32:25 +1000 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E8C1A0.70904@kodewerk.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> Message-ID: <0BBCEF18-9277-4FBD-A337-775CB46E6742@atlassian.com> Kirk, Thanks for the info. I will try NetBeans and look at what it tells me - this is certainly a lot more useful than what the other tools have been able to give me. Unfortunately it is Saturday morning in Sydney and I will not be able to attempt with generations on until Monday. As reported below, we have verified that the IBM JVM does not leak the plugin system classes. cheers, jed. On 18/04/2009, at 3:51 AM, kirk wrote: > Hi Jed, > > I've had a quick look at the heap dump. I'm having a little trouble > understanding what is in there. What I can see is a large number of > java.lang.reflect.Method objects being held. There seems to be two > competing patterns of references holding onto these objects. I've > attached some screenshots rather than use words. > > The scary thing is that the references include ClassLoader.scl, > JDK12Hooks.systemClassLoader as well as Apache commons logging > LogFactory. With this type of the complex entanglement it would seem > unlikely that these objects would ever be collected. The other > pattern also includes the spiders web of references. It also > includes UberspecImpl and a whole bunch of static collections. IME, > static collections are involved in the vast majority of leaks I've > diagnosed. > > Interestingly enough the a portion of the 2nd largest consumer of > memory is also tangled up in the JDK12Hooks. Random sampling leads > me to AST parse trees and "no reference". Looks like much of this is > tied up with Velocity. In fact the largest consumer of memory at 24% > is char[]. I'm failing to find anything that is not tied up with > Velocity (AST parsing). > > Needs more investigation. Be interesting to run a test with > generations turned on. NetBeans generations is a true count unlike > that provided by YourKit. > > Regards, > Kirk > > > Jed Wesley-Smith wrote: >> Classes as well. We end up getting an OOME although the profilers >> report only a third of the heap is reachable. >> >> Although I indicated we saw this on the IBM jdk analysis of that >> dump showed a completely different issue that apparently may not be >> a problem (due to reflection optimisation on that jdk) - the dead >> objects appear to have been correctly cleared. We are reproducing >> this to verify. >> >> Additionally we tried running with -client on the sun jvms as we >> saw a bug that might have caused it reported against server only >> but without success. >> >> cheers, >> jed. >> >> On 16/04/2009, at 12:51 AM, Tony Printezis > > wrote: >> >>> OK, I'll bite. >>> >>> When you say: "a large section of memory (a plugin framework)" do >>> you mean only objects in the young / old gen, or also classes in >>> the perm gen? >>> >>> How do you know that said memory is not being reclaimed? Do you >>> eventually get an OOM? >>> >>> Given that it happens with two different JVMs (I assume you use >>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely >>> to be a GC bug, as both JVMs would need to have the same bug. Not >>> impossible, but unlikely, IMHO. >>> >>> Tony >>> >>> Jed Wesley-Smith wrote: >>>> all, >>>> >>>> I am writing to this list in some desperation hoping for some >>>> expert advice. We (the JIRA development team at Atlassian) have >>>> been hunting memory leaks for some weeks and in the process have >>>> tracked down and removed every possible reference to a large >>>> section of memory (a plugin framework) that we could find. >>>> Starting with all strong references and proceeding to remove soft >>>> and weak references - even things like clearing the >>>> java.lang.reflect.Proxy cache - and even Finalizer references >>>> until both YourKit, Eclipse MAT, JProfiler and jhat all report >>>> that the memory in question is dead and should be collectable, >>>> but inexplicably _the JVM still holds on to it_. There are no JNI >>>> Global references either, yet this memory remains uncollectable! >>>> >>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the >>>> IBM 1.6 JDK on Linux. >>>> >>>> So my question is, how on earth do I search for what is >>>> referencing this uncollectable memory? Are there any other tools >>>> that can help find why this memory is not collected? Can I query >>>> the VM directly somehow? >>>> >>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>> find the heap root (i.e. according to "the rules" there is no >>>> heap root). Are there any known GC memory leaks caused by >>>> ClassLoaders being dropped for instance? >>>> >>>> The application is creating and disposing of a lot of >>>> ClassLoaders via OSGi (Apache Felix) with Spring OSGi. It creates >>>> a lot of java.lang.reflect.Proxy class instances. >>>> >>>> We have written this up and added an example heap dump here: >>>> http://jira.atlassian.com/browse/JRA-16932 >>>> >>>> Having come to the end of our tethers here, if anyone can help in >>>> any way it would be massively appreciated. >>>> >>>> cheers, >>>> Jed Wesley-Smith >>>> JIRA Team @ Atlassian >>> >>> -- >>> --------------------------------------------------------------------- >>> | 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 jed at atlassian.com Mon Apr 20 01:13:06 2009 From: jed at atlassian.com (Jed Wesley-Smith) Date: Mon, 20 Apr 2009 18:13:06 +1000 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49E8C1A0.70904@kodewerk.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> Message-ID: <49EC2E92.2070501@atlassian.com> Hi Kirk, Having had a chance to look more into your findings I think we are getting somewhere, but I still have some questions. The java.lang.reflect.Method count definitely looks like a problem, but I it is a by-product of one of the things I was using to eliminate (noisy) references - specifically the weak references that were coming java.lang.reflect.Proxy.loaderToCache and java.lang.reflect.Proxy. Unfortunately removing the caching meant that these proxies get recreated and hence the Method objects get recreated. I removed this code and rerun the tests and can confirm that the number of Method objects is now much smaller (10k). Of more specific interest to us is the number of objects that have no GC root. I was hoping that the NetBeans analyzer might be able to identify a root that all the other analyzers had failed to find. For instance if I look at the instances of the "JiraPluginManager" I see over a dozen instances (there should normally only be one and never be more than two - while the plugin system is reloading). If I ask the NetBeans profiler (like every other profiler) for the nearest GC root it says that none is found. There should only be about 50MB of reachable heap but there is ~80MB dark heap that will not be GC'd by the Sun JVM. Another interesting case in point is the hundreds of DefaultPicoContainer instances with no GC root. These guys have fairly tightly circular reference chains with the various ComponentAdapter instances, but will not die. Also check out the ASTReference instances. These seem to have some of the tightest We have definitely established that there is no memory leak under the IBM JDK. The aforementioned Proxy cache clearing was causing problems with heap growth but once we removed that it went away. Our stab in the dark theory about this is that there is somehow just too much densely circular referenced heap chains living in the old gen that are somehow causing the GC algorithm to choke. The fact that the CMS collector helps to some extent does seem to support this theory. On the converse to this theory is that reducing the application's workload to zero and repeatedly asking it to full GC it will not release any further heap. We have looked at all finalizers and the most that any of them do is to call JarFile.close(). Following is the list of objects that may be finalized: 1 com.sun.crypto.provider.PBEKey 71 java.io.FileInputStream 10 java.io.FileOutputStream 7 java.lang.ClassLoader$NativeLibrary 14 java.net.SocksSocketImpl 22 java.util.Timer$1 1 java.util.concurrent.ScheduledThreadPoolExecutor 2 java.util.concurrent.ThreadPoolExecutor 227 java.util.jar.JarFile 288 java.util.zip.Inflater 143 org.apache.felix.framework.cache.JarContent 2 org.apache.log4j.ConsoleAppender 6 org.apache.log4j.RollingFileAppender 1 org.hsqldb.Database 8 org.hsqldb.jdbc.jdbcConnection 1 org.hsqldb.persist.NIOLockFile 1 org.hsqldb.scriptio.ScriptWriterText 86 sun.net.www.protocol.jar.URLJarFile None of them contain references back to any of the application. If anyone can help us understand why the JiraPluginManager and other instances listed above remain under the Sun JVM it would be most appreciated. cheers, jed. kirk wrote: > Hi Jed, > > I've had a quick look at the heap dump. I'm having a little trouble > understanding what is in there. What I can see is a large number of > java.lang.reflect.Method objects being held. There seems to be two > competing patterns of references holding onto these objects. I've > attached some screenshots rather than use words. > > The scary thing is that the references include ClassLoader.scl, > JDK12Hooks.systemClassLoader as well as Apache commons logging > LogFactory. With this type of the complex entanglement it would seem > unlikely that these objects would ever be collected. The other pattern > also includes the spiders web of references. It also includes > UberspecImpl and a whole bunch of static collections. IME, static > collections are involved in the vast majority of leaks I've diagnosed. > > Interestingly enough the a portion of the 2nd largest consumer of > memory is also tangled up in the JDK12Hooks. Random sampling leads me > to AST parse trees and "no reference". Looks like much of this is tied > up with Velocity. In fact the largest consumer of memory at 24% is > char[]. I'm failing to find anything that is not tied up with Velocity > (AST parsing). > > Needs more investigation. Be interesting to run a test with > generations turned on. NetBeans generations is a true count unlike > that provided by YourKit. > > Regards, > Kirk > > > Jed Wesley-Smith wrote: >> Classes as well. We end up getting an OOME although the profilers >> report only a third of the heap is reachable. >> >> Although I indicated we saw this on the IBM jdk analysis of that dump >> showed a completely different issue that apparently may not be a >> problem (due to reflection optimisation on that jdk) - the dead >> objects appear to have been correctly cleared. We are reproducing >> this to verify. >> >> Additionally we tried running with -client on the sun jvms as we saw >> a bug that might have caused it reported against server only but >> without success. >> >> cheers, >> jed. >> >> On 16/04/2009, at 12:51 AM, Tony Printezis >> wrote: >> >>> OK, I'll bite. >>> >>> When you say: "a large section of memory (a plugin framework)" do >>> you mean only objects in the young / old gen, or also classes in the >>> perm gen? >>> >>> How do you know that said memory is not being reclaimed? Do you >>> eventually get an OOM? >>> >>> Given that it happens with two different JVMs (I assume you use >>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to >>> be a GC bug, as both JVMs would need to have the same bug. Not >>> impossible, but unlikely, IMHO. >>> >>> Tony >>> >>> Jed Wesley-Smith wrote: >>>> all, >>>> >>>> I am writing to this list in some desperation hoping for some >>>> expert advice. We (the JIRA development team at Atlassian) have >>>> been hunting memory leaks for some weeks and in the process have >>>> tracked down and removed every possible reference to a large >>>> section of memory (a plugin framework) that we could find. Starting >>>> with all strong references and proceeding to remove soft and weak >>>> references - even things like clearing the java.lang.reflect.Proxy >>>> cache - and even Finalizer references until both YourKit, Eclipse >>>> MAT, JProfiler and jhat all report that the memory in question is >>>> dead and should be collectable, but inexplicably _the JVM still >>>> holds on to it_. There are no JNI Global references either, yet >>>> this memory remains uncollectable! >>>> >>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the IBM >>>> 1.6 JDK on Linux. >>>> >>>> So my question is, how on earth do I search for what is referencing >>>> this uncollectable memory? Are there any other tools that can help >>>> find why this memory is not collected? Can I query the VM directly >>>> somehow? >>>> >>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>> find the heap root (i.e. according to "the rules" there is no heap >>>> root). Are there any known GC memory leaks caused by ClassLoaders >>>> being dropped for instance? >>>> >>>> The application is creating and disposing of a lot of ClassLoaders >>>> via OSGi (Apache Felix) with Spring OSGi. It creates a lot of >>>> java.lang.reflect.Proxy class instances. >>>> >>>> We have written this up and added an example heap dump here: >>>> http://jira.atlassian.com/browse/JRA-16932 >>>> >>>> Having come to the end of our tethers here, if anyone can help in >>>> any way it would be massively appreciated. >>>> >>>> cheers, >>>> Jed Wesley-Smith >>>> JIRA Team @ Atlassian From kirk at kodewerk.com Mon Apr 20 02:43:54 2009 From: kirk at kodewerk.com (kirk) Date: Mon, 20 Apr 2009 11:43:54 +0200 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49EC2E92.2070501@atlassian.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> <49EC2E92.2070501@atlassian.com> Message-ID: <49EC43DA.3090608@kodewerk.com> Ok, new information. You are using CMS. By default, CMS doesn't collect perm-space. The class-loader related bits that I saw would be in perm-space. IBM heap is structured very differently and it doesn't contain a perm-space. Your conformation of no leak in IBM JVM points directly to a perm-space leak. Read Frank Kieviet's blogs about perm space. http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java I am on the tipping point about CMS not collecting perm-space by default and perm-space leaks in general. But I can charge nice sums of money fixing them and look like Scotty in the process so I shalln't bite the hand that feeds.. ;-) In your case I'll just be looking for more beer! I was chatting to Tony about the number of int[] arrays in the profile. He mentioned that holes in heap maybe represented as int[] with no GC root. This can be a bit confusing at first glance. JiraPluginManager and DefaultPicoContainer.. hummm. I need to take another look. Ok for the Default PicoContainer I checked the first 10 of 89 instances and was able to locate a GC root for each of them. The first instance has one GC root as a Java frame. Tracing back you get right into apache commons classloaders once again. There are a number of weak links buy more importantly, there are a number of array slots that also keep a grip on these objects. Strangely enough, the first one that I randomly selected had no GC root. IMHO, this object should be collectable and since it hasn't been there are one of two possibilities. It is either in perm space or it is a dead object that wasn't collected prior to the heap dump being taken. A heap dump contains *all* objects, both dead and alive. Best to run GC twice prior to dumping heap. 8 instances of JiraPluginManager. 6 have no GC roots and should be collectable. The first instance is listed as a JavaFrame and the last is tied up with apache commons classloading. See if you can set the CMS perm space sweeping flag, this the System.gc() twice and then re-take a heap dump and send it. I'll have another look Regards, Kirk Jed Wesley-Smith wrote: > Hi Kirk, > > Having had a chance to look more into your findings I think we are > getting somewhere, but I still have some questions. > > The java.lang.reflect.Method count definitely looks like a problem, > but I it is a by-product of one of the things I was using to eliminate > (noisy) references - specifically the weak references that were coming > java.lang.reflect.Proxy.loaderToCache and java.lang.reflect.Proxy. > Unfortunately removing the caching meant that these proxies get > recreated and hence the Method objects get recreated. I removed this > code and rerun the tests and can confirm that the number of Method > objects is now much smaller (10k). > > Of more specific interest to us is the number of objects that have no > GC root. I was hoping that the NetBeans analyzer might be able to > identify a root that all the other analyzers had failed to find. For > instance if I look at the instances of the "JiraPluginManager" I see > over a dozen instances (there should normally only be one and never be > more than two - while the plugin system is reloading). If I ask the > NetBeans profiler (like every other profiler) for the nearest GC root > it says that none is found. There should only be about 50MB of > reachable heap but there is ~80MB dark heap that will not be GC'd by > the Sun JVM. Another interesting case in point is the hundreds of > DefaultPicoContainer instances with no GC root. These guys have fairly > tightly circular reference chains with the various ComponentAdapter > instances, but will not die. Also check out the ASTReference > instances. These seem to have some of the tightest > > We have definitely established that there is no memory leak under the > IBM JDK. The aforementioned Proxy cache clearing was causing problems > with heap growth but once we removed that it went away. > > Our stab in the dark theory about this is that there is somehow just > too much densely circular referenced heap chains living in the old gen > that are somehow causing the GC algorithm to choke. The fact that the > CMS collector helps to some extent does seem to support this theory. > On the converse to this theory is that reducing the application's > workload to zero and repeatedly asking it to full GC it will not > release any further heap. > > We have looked at all finalizers and the most that any of them do is > to call JarFile.close(). Following is the list of objects that may be > finalized: > > 1 com.sun.crypto.provider.PBEKey > 71 java.io.FileInputStream > 10 java.io.FileOutputStream > 7 java.lang.ClassLoader$NativeLibrary > 14 java.net.SocksSocketImpl > 22 java.util.Timer$1 > 1 java.util.concurrent.ScheduledThreadPoolExecutor > 2 java.util.concurrent.ThreadPoolExecutor > 227 java.util.jar.JarFile > 288 java.util.zip.Inflater > 143 org.apache.felix.framework.cache.JarContent > 2 org.apache.log4j.ConsoleAppender > 6 org.apache.log4j.RollingFileAppender > 1 org.hsqldb.Database > 8 org.hsqldb.jdbc.jdbcConnection > 1 org.hsqldb.persist.NIOLockFile > 1 org.hsqldb.scriptio.ScriptWriterText > 86 sun.net.www.protocol.jar.URLJarFile > > None of them contain references back to any of the application. > > If anyone can help us understand why the JiraPluginManager and other > instances listed above remain under the Sun JVM it would be most > appreciated. > > cheers, > jed. > > kirk wrote: >> Hi Jed, >> >> I've had a quick look at the heap dump. I'm having a little trouble >> understanding what is in there. What I can see is a large number of >> java.lang.reflect.Method objects being held. There seems to be two >> competing patterns of references holding onto these objects. I've >> attached some screenshots rather than use words. >> >> The scary thing is that the references include ClassLoader.scl, >> JDK12Hooks.systemClassLoader as well as Apache commons logging >> LogFactory. With this type of the complex entanglement it would seem >> unlikely that these objects would ever be collected. The other >> pattern also includes the spiders web of references. It also includes >> UberspecImpl and a whole bunch of static collections. IME, static >> collections are involved in the vast majority of leaks I've diagnosed. >> >> Interestingly enough the a portion of the 2nd largest consumer of >> memory is also tangled up in the JDK12Hooks. Random sampling leads me >> to AST parse trees and "no reference". Looks like much of this is >> tied up with Velocity. In fact the largest consumer of memory at 24% >> is char[]. I'm failing to find anything that is not tied up with >> Velocity (AST parsing). >> >> Needs more investigation. Be interesting to run a test with >> generations turned on. NetBeans generations is a true count unlike >> that provided by YourKit. >> >> Regards, >> Kirk >> >> >> Jed Wesley-Smith wrote: >>> Classes as well. We end up getting an OOME although the profilers >>> report only a third of the heap is reachable. >>> >>> Although I indicated we saw this on the IBM jdk analysis of that >>> dump showed a completely different issue that apparently may not be >>> a problem (due to reflection optimisation on that jdk) - the dead >>> objects appear to have been correctly cleared. We are reproducing >>> this to verify. >>> >>> Additionally we tried running with -client on the sun jvms as we saw >>> a bug that might have caused it reported against server only but >>> without success. >>> >>> cheers, >>> jed. >>> >>> On 16/04/2009, at 12:51 AM, Tony Printezis >>> wrote: >>> >>>> OK, I'll bite. >>>> >>>> When you say: "a large section of memory (a plugin framework)" do >>>> you mean only objects in the young / old gen, or also classes in >>>> the perm gen? >>>> >>>> How do you know that said memory is not being reclaimed? Do you >>>> eventually get an OOM? >>>> >>>> Given that it happens with two different JVMs (I assume you use >>>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely to >>>> be a GC bug, as both JVMs would need to have the same bug. Not >>>> impossible, but unlikely, IMHO. >>>> >>>> Tony >>>> >>>> Jed Wesley-Smith wrote: >>>>> all, >>>>> >>>>> I am writing to this list in some desperation hoping for some >>>>> expert advice. We (the JIRA development team at Atlassian) have >>>>> been hunting memory leaks for some weeks and in the process have >>>>> tracked down and removed every possible reference to a large >>>>> section of memory (a plugin framework) that we could find. >>>>> Starting with all strong references and proceeding to remove soft >>>>> and weak references - even things like clearing the >>>>> java.lang.reflect.Proxy cache - and even Finalizer references >>>>> until both YourKit, Eclipse MAT, JProfiler and jhat all report >>>>> that the memory in question is dead and should be collectable, but >>>>> inexplicably _the JVM still holds on to it_. There are no JNI >>>>> Global references either, yet this memory remains uncollectable! >>>>> >>>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the >>>>> IBM 1.6 JDK on Linux. >>>>> >>>>> So my question is, how on earth do I search for what is >>>>> referencing this uncollectable memory? Are there any other tools >>>>> that can help find why this memory is not collected? Can I query >>>>> the VM directly somehow? >>>>> >>>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>>> find the heap root (i.e. according to "the rules" there is no heap >>>>> root). Are there any known GC memory leaks caused by ClassLoaders >>>>> being dropped for instance? >>>>> >>>>> The application is creating and disposing of a lot of ClassLoaders >>>>> via OSGi (Apache Felix) with Spring OSGi. It creates a lot of >>>>> java.lang.reflect.Proxy class instances. >>>>> >>>>> We have written this up and added an example heap dump here: >>>>> http://jira.atlassian.com/browse/JRA-16932 >>>>> >>>>> Having come to the end of our tethers here, if anyone can help in >>>>> any way it would be massively appreciated. >>>>> >>>>> cheers, >>>>> Jed Wesley-Smith >>>>> JIRA Team @ Atlassian > > From andrey.petrusenko at sun.com Mon Apr 20 06:25:16 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 20 Apr 2009 13:25:16 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 22 new changesets Message-ID: <20090420132604.09A5EE260@hg.openjdk.java.net> Changeset: 6e56a851ccaa Author: xdono Date: 2009-03-27 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6e56a851ccaa Added tag jdk7-b52 for changeset 1b1e8f1a4fe8 ! .hgtags Changeset: 032c6af894da Author: trims Date: 2009-04-01 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/032c6af894da Merge Changeset: a9d9d7e06593 Author: trims Date: 2009-04-02 17:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a9d9d7e06593 Merge Changeset: aa3a6f3eaa43 Author: trims Date: 2009-04-02 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/aa3a6f3eaa43 6825815: Bump HS15 build number to 05 and update copyright date of HOTSPOT_VM_COPYRIGHT Summary: Update the HS15 Build number to 05 and fix copyright date of HOTSPOT_VM_COPYRIGHT Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5450320b9c27 Author: xdono Date: 2009-04-02 16:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5450320b9c27 Added tag jdk7-b53 for changeset 032c6af894da ! .hgtags Changeset: 5373f8d7025b Author: trims Date: 2009-04-02 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5373f8d7025b Merge Changeset: eae95c5579a4 Author: trims Date: 2009-04-03 19:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/eae95c5579a4 Merge Changeset: fafab5d5349c Author: trims Date: 2009-04-03 20:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fafab5d5349c Merge Changeset: a63bc96715a9 Author: trims Date: 2009-04-08 14:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a63bc96715a9 6828076: Fork HS15 to HS16 - renumber Major and build numbers of JVM Summary: Update the Hotspot version number to HS16 B01 for HS16 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: b9fba36710f2 Author: xlu Date: 2009-04-06 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b9fba36710f2 6699669: Hotspot server leaves synchronized block with monitor in bad state Summary: Remove usage of _highest_lock field in Thread so that is_lock_owned won't depend on the correct update of that field. Reviewed-by: never, dice, acorn ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 68cd0d7ee9bb Author: xlu Date: 2009-04-09 13:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/68cd0d7ee9bb Merge Changeset: ad8c635e757e Author: kvn Date: 2009-04-03 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/ad8c635e757e 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph") Summary: Use a HaltNode on the fall through path of the AllocateArrayNode to indicate that it is unreachable if the array length is negative. Reviewed-by: never, jrose ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp + test/compiler/6823453/Test.java Changeset: 1f2abec69714 Author: never Date: 2009-04-03 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1f2abec69714 6826261: class file dumping from SA is broken Reviewed-by: kvn, jcoomes ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java Changeset: 819880572f09 Author: never Date: 2009-04-06 11:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/819880572f09 6539464: Math.log() produces inconsistent results between successive runs. Reviewed-by: kvn ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/6539464/Test.java Changeset: 4ec1257180ec Author: kvn Date: 2009-04-07 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4ec1257180ec 6826960: C2 Sparc: assert(bb->_nodes(_bb_end)->is_Proj(),"skipping projections after expected call") Summary: Add the check when a Halt node is placed in a separate block. Reviewed-by: twisti ! src/share/vm/opto/output.cpp Changeset: f2049ae95c3d Author: kvn Date: 2009-04-07 19:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f2049ae95c3d 6711117: Assertion in 64bit server vm (flat != TypePtr::BOTTOM,"cannot alias-analyze an untyped ptr") Summary: Delay a memory node transformation if its control or address on IGVN worklist. Reviewed-by: never ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp + test/compiler/6711117/Test.java Changeset: 1d037ecd7960 Author: jrose Date: 2009-04-08 00:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1d037ecd7960 6827505: sizing logic for vtable and itable stubs needs self-check Summary: Asserts and comments to help maintain the correct sizing of certain stubs Reviewed-by: kvn ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/code/vtableStubs.cpp Changeset: e5b0439ef4ae Author: jrose Date: 2009-04-08 10:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/e5b0439ef4ae 6655638: dynamic languages need method handles Summary: initial implementation, with known omissions (x86/64, sparc, compiler optim., c-oops, C++ interp.) Reviewed-by: kvn, twisti, never ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/register_definitions_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp + src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp + src/share/vm/prims/methodHandles.cpp + src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 9610b2a8ab4e Author: cfang Date: 2009-04-10 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9610b2a8ab4e 6829021: tests for 6636138 use UseSuperword instead of UseSuperWord Summary: Remove the wrong flag -XX:+UseSuperword to fix the Nightly failure Reviewed-by: kvn, never ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: 6e33bfd4139b Author: never Date: 2009-04-14 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6e33bfd4139b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4961a8a726a4 Author: trims Date: 2009-04-15 21:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4961a8a726a4 6830815: jprt.config not setting proper compiler version for use in 6u14 Summary: Add the 6u14 option to the jprt.config file in workspace Reviewed-by: ohair ! make/jprt.config Changeset: 981375ca07b7 Author: never Date: 2009-04-17 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/981375ca07b7 6831604: missing null check in guarantee Reviewed-by: kvn ! src/share/vm/memory/dump.cpp From jed at atlassian.com Mon Apr 20 17:45:07 2009 From: jed at atlassian.com (Jed Wesley-Smith) Date: Tue, 21 Apr 2009 10:45:07 +1000 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49EC43DA.3090608@kodewerk.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> <49EC2E92.2070501@atlassian.com> <49EC43DA.3090608@kodewerk.com> Message-ID: <49ED1713.5070507@atlassian.com> Thanks for the help kirk, The original heap that is up on the issue _was not_ using CMS, just some of my latest tests. I haven't published a CMS heap. The heap provided was generated using the default GC algorithm and -XX:+HeapDumpOnOutOfMemoryError. As far as I am aware (please correct me if I am wrong) the collector _should_ have done a full GC prior to throwing an OOME - therefore I expect things that have no discernable heap root should have been collected, but the evidence is that there are massive numbers of these objects around and clearly are not collected by the Sun JVM. This is the crux of the problem. Also, if there was a permgen root I would expect to be able to find it :-) I will provide some more detailed responses and information later. cheers, jed. kirk wrote: > Ok, new information. You are using CMS. By default, CMS doesn't > collect perm-space. The class-loader related bits that I saw would be > in perm-space. IBM heap is structured very differently and it doesn't > contain a perm-space. Your conformation of no leak in IBM JVM points > directly to a perm-space leak. Read Frank Kieviet's blogs about perm > space. > http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java > > I am on the tipping point about CMS not collecting perm-space by > default and perm-space leaks in general. But I can charge nice sums of > money fixing them and look like Scotty in the process so I shalln't > bite the hand that feeds.. ;-) In your case I'll just be looking for > more beer! > > I was chatting to Tony about the number of int[] arrays in the > profile. He mentioned that holes in heap maybe represented as int[] > with no GC root. This can be a bit confusing at first glance. > > JiraPluginManager and DefaultPicoContainer.. hummm. I need to take > another look. > Ok for the Default PicoContainer I checked the first 10 of 89 > instances and was able to locate a GC root for each of them. The first > instance has one GC root as a Java frame. Tracing back you get right > into apache commons classloaders once again. There are a number of > weak links buy more importantly, there are a number of array slots > that also keep a grip on these objects. Strangely enough, the first > one that I randomly selected had no GC root. IMHO, this object should > be collectable and since it hasn't been there are one of two > possibilities. It is either in perm space or it is a dead object that > wasn't collected prior to the heap dump being taken. A heap dump > contains *all* objects, both dead and alive. Best to run GC twice > prior to dumping heap. > > 8 instances of JiraPluginManager. 6 have no GC roots and should be > collectable. The first instance is listed as a JavaFrame and the last > is tied up with apache commons classloading. > > See if you can set the CMS perm space sweeping flag, this the > System.gc() twice and then re-take a heap dump and send it. I'll have > another look > > Regards, > Kirk > > > Jed Wesley-Smith wrote: >> Hi Kirk, >> >> Having had a chance to look more into your findings I think we are >> getting somewhere, but I still have some questions. >> >> The java.lang.reflect.Method count definitely looks like a problem, >> but I it is a by-product of one of the things I was using to >> eliminate (noisy) references - specifically the weak references that >> were coming java.lang.reflect.Proxy.loaderToCache and >> java.lang.reflect.Proxy. Unfortunately removing the caching meant >> that these proxies get recreated and hence the Method objects get >> recreated. I removed this code and rerun the tests and can confirm >> that the number of Method objects is now much smaller (10k). >> >> Of more specific interest to us is the number of objects that have no >> GC root. I was hoping that the NetBeans analyzer might be able to >> identify a root that all the other analyzers had failed to find. For >> instance if I look at the instances of the "JiraPluginManager" I see >> over a dozen instances (there should normally only be one and never >> be more than two - while the plugin system is reloading). If I ask >> the NetBeans profiler (like every other profiler) for the nearest GC >> root it says that none is found. There should only be about 50MB of >> reachable heap but there is ~80MB dark heap that will not be GC'd by >> the Sun JVM. Another interesting case in point is the hundreds of >> DefaultPicoContainer instances with no GC root. These guys have >> fairly tightly circular reference chains with the various >> ComponentAdapter instances, but will not die. Also check out the >> ASTReference instances. These seem to have some of the tightest >> >> We have definitely established that there is no memory leak under the >> IBM JDK. The aforementioned Proxy cache clearing was causing problems >> with heap growth but once we removed that it went away. >> >> Our stab in the dark theory about this is that there is somehow just >> too much densely circular referenced heap chains living in the old >> gen that are somehow causing the GC algorithm to choke. The fact that >> the CMS collector helps to some extent does seem to support this >> theory. On the converse to this theory is that reducing the >> application's workload to zero and repeatedly asking it to full GC it >> will not release any further heap. >> >> We have looked at all finalizers and the most that any of them do is >> to call JarFile.close(). Following is the list of objects that may be >> finalized: >> >> 1 com.sun.crypto.provider.PBEKey >> 71 java.io.FileInputStream >> 10 java.io.FileOutputStream >> 7 java.lang.ClassLoader$NativeLibrary >> 14 java.net.SocksSocketImpl >> 22 java.util.Timer$1 >> 1 java.util.concurrent.ScheduledThreadPoolExecutor >> 2 java.util.concurrent.ThreadPoolExecutor >> 227 java.util.jar.JarFile >> 288 java.util.zip.Inflater >> 143 org.apache.felix.framework.cache.JarContent >> 2 org.apache.log4j.ConsoleAppender >> 6 org.apache.log4j.RollingFileAppender >> 1 org.hsqldb.Database >> 8 org.hsqldb.jdbc.jdbcConnection >> 1 org.hsqldb.persist.NIOLockFile >> 1 org.hsqldb.scriptio.ScriptWriterText >> 86 sun.net.www.protocol.jar.URLJarFile >> >> None of them contain references back to any of the application. >> >> If anyone can help us understand why the JiraPluginManager and other >> instances listed above remain under the Sun JVM it would be most >> appreciated. >> >> cheers, >> jed. >> >> kirk wrote: >>> Hi Jed, >>> >>> I've had a quick look at the heap dump. I'm having a little trouble >>> understanding what is in there. What I can see is a large number of >>> java.lang.reflect.Method objects being held. There seems to be two >>> competing patterns of references holding onto these objects. I've >>> attached some screenshots rather than use words. >>> >>> The scary thing is that the references include ClassLoader.scl, >>> JDK12Hooks.systemClassLoader as well as Apache commons logging >>> LogFactory. With this type of the complex entanglement it would seem >>> unlikely that these objects would ever be collected. The other >>> pattern also includes the spiders web of references. It also >>> includes UberspecImpl and a whole bunch of static collections. IME, >>> static collections are involved in the vast majority of leaks I've >>> diagnosed. >>> >>> Interestingly enough the a portion of the 2nd largest consumer of >>> memory is also tangled up in the JDK12Hooks. Random sampling leads >>> me to AST parse trees and "no reference". Looks like much of this is >>> tied up with Velocity. In fact the largest consumer of memory at 24% >>> is char[]. I'm failing to find anything that is not tied up with >>> Velocity (AST parsing). >>> >>> Needs more investigation. Be interesting to run a test with >>> generations turned on. NetBeans generations is a true count unlike >>> that provided by YourKit. >>> >>> Regards, >>> Kirk >>> >>> >>> Jed Wesley-Smith wrote: >>>> Classes as well. We end up getting an OOME although the profilers >>>> report only a third of the heap is reachable. >>>> >>>> Although I indicated we saw this on the IBM jdk analysis of that >>>> dump showed a completely different issue that apparently may not be >>>> a problem (due to reflection optimisation on that jdk) - the dead >>>> objects appear to have been correctly cleared. We are reproducing >>>> this to verify. >>>> >>>> Additionally we tried running with -client on the sun jvms as we >>>> saw a bug that might have caused it reported against server only >>>> but without success. >>>> >>>> cheers, >>>> jed. >>>> >>>> On 16/04/2009, at 12:51 AM, Tony Printezis >>>> wrote: >>>> >>>>> OK, I'll bite. >>>>> >>>>> When you say: "a large section of memory (a plugin framework)" do >>>>> you mean only objects in the young / old gen, or also classes in >>>>> the perm gen? >>>>> >>>>> How do you know that said memory is not being reclaimed? Do you >>>>> eventually get an OOM? >>>>> >>>>> Given that it happens with two different JVMs (I assume you use >>>>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely >>>>> to be a GC bug, as both JVMs would need to have the same bug. Not >>>>> impossible, but unlikely, IMHO. >>>>> >>>>> Tony >>>>> >>>>> Jed Wesley-Smith wrote: >>>>>> all, >>>>>> >>>>>> I am writing to this list in some desperation hoping for some >>>>>> expert advice. We (the JIRA development team at Atlassian) have >>>>>> been hunting memory leaks for some weeks and in the process have >>>>>> tracked down and removed every possible reference to a large >>>>>> section of memory (a plugin framework) that we could find. >>>>>> Starting with all strong references and proceeding to remove soft >>>>>> and weak references - even things like clearing the >>>>>> java.lang.reflect.Proxy cache - and even Finalizer references >>>>>> until both YourKit, Eclipse MAT, JProfiler and jhat all report >>>>>> that the memory in question is dead and should be collectable, >>>>>> but inexplicably _the JVM still holds on to it_. There are no JNI >>>>>> Global references either, yet this memory remains uncollectable! >>>>>> >>>>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the >>>>>> IBM 1.6 JDK on Linux. >>>>>> >>>>>> So my question is, how on earth do I search for what is >>>>>> referencing this uncollectable memory? Are there any other tools >>>>>> that can help find why this memory is not collected? Can I query >>>>>> the VM directly somehow? >>>>>> >>>>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>>>> find the heap root (i.e. according to "the rules" there is no >>>>>> heap root). Are there any known GC memory leaks caused by >>>>>> ClassLoaders being dropped for instance? >>>>>> >>>>>> The application is creating and disposing of a lot of >>>>>> ClassLoaders via OSGi (Apache Felix) with Spring OSGi. It creates >>>>>> a lot of java.lang.reflect.Proxy class instances. >>>>>> >>>>>> We have written this up and added an example heap dump here: >>>>>> http://jira.atlassian.com/browse/JRA-16932 >>>>>> >>>>>> Having come to the end of our tethers here, if anyone can help in >>>>>> any way it would be massively appreciated. >>>>>> >>>>>> cheers, >>>>>> Jed Wesley-Smith >>>>>> JIRA Team @ Atlassian >> >> > From jed at atlassian.com Mon Apr 20 18:49:22 2009 From: jed at atlassian.com (Jed Wesley-Smith) Date: Tue, 21 Apr 2009 11:49:22 +1000 Subject: the amazing tales of the search for the invisible man! or, where's my gc root In-Reply-To: <49EC43DA.3090608@kodewerk.com> References: <49E416C0.2090808@atlassian.com> <49E5F466.5020600@sun.com> <49E8C1A0.70904@kodewerk.com> <49EC2E92.2070501@atlassian.com> <49EC43DA.3090608@kodewerk.com> Message-ID: <49ED2622.6070101@atlassian.com> kirk, to be clear my tests have shown the following: MacOSX (64 bit) java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) 256MB default GC: starts at 8 secs per test then goes to 30 secs, then 60+ then throws OOME after approx 50 runs 256MB CMS GC () : does not throw OOME but slow down 10x and spend +80% in GC after only a few runs 256MB Parallel GC: throws OOME after approx 40 runs Linux: (quite old java version - 32 bit) java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode) 128MB default GC does not throw OOME and does not slow down but is slow from the beginning (30 secs per test) IBM JDK (32 bit): java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr4-20090219_01(SR4)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20090215_29883 (JIT enabled, AOT enabled) J9VM - 20090215_029883_lHdSMr JIT - r9_20090213_2028 GC - 20090213_AA) JCL - 20090218_01 128MB default does not throw OOME and does not slow down. No Observations: * There are definite tipping points at which the GC suddenly starts working a lot harder in the Sun JVM tests and the performance becomes significantly worse. * All heap dumps from the Sun JVMs contain large sections of heap with no discoverable heap root. All are produced by HeapDumpOnOOME or after pressing the big red Full GC button plenty of times. cheers, jed. kirk wrote: > Ok, new information. You are using CMS. By default, CMS doesn't > collect perm-space. The class-loader related bits that I saw would be > in perm-space. IBM heap is structured very differently and it doesn't > contain a perm-space. Your conformation of no leak in IBM JVM points > directly to a perm-space leak. Read Frank Kieviet's blogs about perm > space. > http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java > > I am on the tipping point about CMS not collecting perm-space by > default and perm-space leaks in general. But I can charge nice sums of > money fixing them and look like Scotty in the process so I shalln't > bite the hand that feeds.. ;-) In your case I'll just be looking for > more beer! > > I was chatting to Tony about the number of int[] arrays in the > profile. He mentioned that holes in heap maybe represented as int[] > with no GC root. This can be a bit confusing at first glance. > > JiraPluginManager and DefaultPicoContainer.. hummm. I need to take > another look. > Ok for the Default PicoContainer I checked the first 10 of 89 > instances and was able to locate a GC root for each of them. The first > instance has one GC root as a Java frame. Tracing back you get right > into apache commons classloaders once again. There are a number of > weak links buy more importantly, there are a number of array slots > that also keep a grip on these objects. Strangely enough, the first > one that I randomly selected had no GC root. IMHO, this object should > be collectable and since it hasn't been there are one of two > possibilities. It is either in perm space or it is a dead object that > wasn't collected prior to the heap dump being taken. A heap dump > contains *all* objects, both dead and alive. Best to run GC twice > prior to dumping heap. > > 8 instances of JiraPluginManager. 6 have no GC roots and should be > collectable. The first instance is listed as a JavaFrame and the last > is tied up with apache commons classloading. > > See if you can set the CMS perm space sweeping flag, this the > System.gc() twice and then re-take a heap dump and send it. I'll have > another look > > Regards, > Kirk > > > Jed Wesley-Smith wrote: >> Hi Kirk, >> >> Having had a chance to look more into your findings I think we are >> getting somewhere, but I still have some questions. >> >> The java.lang.reflect.Method count definitely looks like a problem, >> but I it is a by-product of one of the things I was using to >> eliminate (noisy) references - specifically the weak references that >> were coming java.lang.reflect.Proxy.loaderToCache and >> java.lang.reflect.Proxy. Unfortunately removing the caching meant >> that these proxies get recreated and hence the Method objects get >> recreated. I removed this code and rerun the tests and can confirm >> that the number of Method objects is now much smaller (10k). >> >> Of more specific interest to us is the number of objects that have no >> GC root. I was hoping that the NetBeans analyzer might be able to >> identify a root that all the other analyzers had failed to find. For >> instance if I look at the instances of the "JiraPluginManager" I see >> over a dozen instances (there should normally only be one and never >> be more than two - while the plugin system is reloading). If I ask >> the NetBeans profiler (like every other profiler) for the nearest GC >> root it says that none is found. There should only be about 50MB of >> reachable heap but there is ~80MB dark heap that will not be GC'd by >> the Sun JVM. Another interesting case in point is the hundreds of >> DefaultPicoContainer instances with no GC root. These guys have >> fairly tightly circular reference chains with the various >> ComponentAdapter instances, but will not die. Also check out the >> ASTReference instances. These seem to have some of the tightest >> >> We have definitely established that there is no memory leak under the >> IBM JDK. The aforementioned Proxy cache clearing was causing problems >> with heap growth but once we removed that it went away. >> >> Our stab in the dark theory about this is that there is somehow just >> too much densely circular referenced heap chains living in the old >> gen that are somehow causing the GC algorithm to choke. The fact that >> the CMS collector helps to some extent does seem to support this >> theory. On the converse to this theory is that reducing the >> application's workload to zero and repeatedly asking it to full GC it >> will not release any further heap. >> >> We have looked at all finalizers and the most that any of them do is >> to call JarFile.close(). Following is the list of objects that may be >> finalized: >> >> 1 com.sun.crypto.provider.PBEKey >> 71 java.io.FileInputStream >> 10 java.io.FileOutputStream >> 7 java.lang.ClassLoader$NativeLibrary >> 14 java.net.SocksSocketImpl >> 22 java.util.Timer$1 >> 1 java.util.concurrent.ScheduledThreadPoolExecutor >> 2 java.util.concurrent.ThreadPoolExecutor >> 227 java.util.jar.JarFile >> 288 java.util.zip.Inflater >> 143 org.apache.felix.framework.cache.JarContent >> 2 org.apache.log4j.ConsoleAppender >> 6 org.apache.log4j.RollingFileAppender >> 1 org.hsqldb.Database >> 8 org.hsqldb.jdbc.jdbcConnection >> 1 org.hsqldb.persist.NIOLockFile >> 1 org.hsqldb.scriptio.ScriptWriterText >> 86 sun.net.www.protocol.jar.URLJarFile >> >> None of them contain references back to any of the application. >> >> If anyone can help us understand why the JiraPluginManager and other >> instances listed above remain under the Sun JVM it would be most >> appreciated. >> >> cheers, >> jed. >> >> kirk wrote: >>> Hi Jed, >>> >>> I've had a quick look at the heap dump. I'm having a little trouble >>> understanding what is in there. What I can see is a large number of >>> java.lang.reflect.Method objects being held. There seems to be two >>> competing patterns of references holding onto these objects. I've >>> attached some screenshots rather than use words. >>> >>> The scary thing is that the references include ClassLoader.scl, >>> JDK12Hooks.systemClassLoader as well as Apache commons logging >>> LogFactory. With this type of the complex entanglement it would seem >>> unlikely that these objects would ever be collected. The other >>> pattern also includes the spiders web of references. It also >>> includes UberspecImpl and a whole bunch of static collections. IME, >>> static collections are involved in the vast majority of leaks I've >>> diagnosed. >>> >>> Interestingly enough the a portion of the 2nd largest consumer of >>> memory is also tangled up in the JDK12Hooks. Random sampling leads >>> me to AST parse trees and "no reference". Looks like much of this is >>> tied up with Velocity. In fact the largest consumer of memory at 24% >>> is char[]. I'm failing to find anything that is not tied up with >>> Velocity (AST parsing). >>> >>> Needs more investigation. Be interesting to run a test with >>> generations turned on. NetBeans generations is a true count unlike >>> that provided by YourKit. >>> >>> Regards, >>> Kirk >>> >>> >>> Jed Wesley-Smith wrote: >>>> Classes as well. We end up getting an OOME although the profilers >>>> report only a third of the heap is reachable. >>>> >>>> Although I indicated we saw this on the IBM jdk analysis of that >>>> dump showed a completely different issue that apparently may not be >>>> a problem (due to reflection optimisation on that jdk) - the dead >>>> objects appear to have been correctly cleared. We are reproducing >>>> this to verify. >>>> >>>> Additionally we tried running with -client on the sun jvms as we >>>> saw a bug that might have caused it reported against server only >>>> but without success. >>>> >>>> cheers, >>>> jed. >>>> >>>> On 16/04/2009, at 12:51 AM, Tony Printezis >>>> wrote: >>>> >>>>> OK, I'll bite. >>>>> >>>>> When you say: "a large section of memory (a plugin framework)" do >>>>> you mean only objects in the young / old gen, or also classes in >>>>> the perm gen? >>>>> >>>>> How do you know that said memory is not being reclaimed? Do you >>>>> eventually get an OOM? >>>>> >>>>> Given that it happens with two different JVMs (I assume you use >>>>> HotSpot on Linux and Mac, as well as the IBM JDK), it's unlikely >>>>> to be a GC bug, as both JVMs would need to have the same bug. Not >>>>> impossible, but unlikely, IMHO. >>>>> >>>>> Tony >>>>> >>>>> Jed Wesley-Smith wrote: >>>>>> all, >>>>>> >>>>>> I am writing to this list in some desperation hoping for some >>>>>> expert advice. We (the JIRA development team at Atlassian) have >>>>>> been hunting memory leaks for some weeks and in the process have >>>>>> tracked down and removed every possible reference to a large >>>>>> section of memory (a plugin framework) that we could find. >>>>>> Starting with all strong references and proceeding to remove soft >>>>>> and weak references - even things like clearing the >>>>>> java.lang.reflect.Proxy cache - and even Finalizer references >>>>>> until both YourKit, Eclipse MAT, JProfiler and jhat all report >>>>>> that the memory in question is dead and should be collectable, >>>>>> but inexplicably _the JVM still holds on to it_. There are no JNI >>>>>> Global references either, yet this memory remains uncollectable! >>>>>> >>>>>> This happens for the 1.5 and 1.6 JVMs on Linux and Mac, and the >>>>>> IBM 1.6 JDK on Linux. >>>>>> >>>>>> So my question is, how on earth do I search for what is >>>>>> referencing this uncollectable memory? Are there any other tools >>>>>> that can help find why this memory is not collected? Can I query >>>>>> the VM directly somehow? >>>>>> >>>>>> I fear this is a JVM GC bug as no known memory analysis tool can >>>>>> find the heap root (i.e. according to "the rules" there is no >>>>>> heap root). Are there any known GC memory leaks caused by >>>>>> ClassLoaders being dropped for instance? >>>>>> >>>>>> The application is creating and disposing of a lot of >>>>>> ClassLoaders via OSGi (Apache Felix) with Spring OSGi. It creates >>>>>> a lot of java.lang.reflect.Proxy class instances. >>>>>> >>>>>> We have written this up and added an example heap dump here: >>>>>> http://jira.atlassian.com/browse/JRA-16932 >>>>>> >>>>>> Having come to the end of our tethers here, if anyone can help in >>>>>> any way it would be massively appreciated. >>>>>> >>>>>> cheers, >>>>>> Jed Wesley-Smith >>>>>> JIRA Team @ Atlassian >> >> > From Jon.Masamitsu at Sun.COM Mon Apr 20 19:46:08 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 20 Apr 2009 19:46:08 -0700 Subject: frequent CMS collections/ CPU spike/ Hotspot JRE1.4.2_17/ In-Reply-To: References: Message-ID: <49ED3370.2000701@sun.com> With a total heap of 768m and a young gen pf 500m you might not have enough room in the tenured (old) gen. That is, the amount of free space left in the tenured gen may be so small that CMS thinks it need to start a collection immediately. Try a larger total heap or a smaller yount gen. I see that you're turning on -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=128 so everything that survives a young gen is being promoted to the tenured gen. Those values reduce the CMS pause times but also fill up the tenured generation faster. If you don't have a specific reason to use those values, 15 for the tenuring threshold and 6 or 8 for the survivor ratio may serve you better. vasu ts wrote On 04/20/09 16:50,: > Hi all, > > We have an application which is deployed on IBM websphere 5.1/Solaris > 5.9/Sun hotspot JRE1.4.2_17/. We have 4 JVM's which are running on the > same machine. > These JVM's recieve xml messages from MQ queue which are processed ( > business logic stores the data from xml into database) and xml replies > are sent back to the MQ queue. > > Hardware > 8 dual core - sparc IV > 4 single core - sparc III > > JRE options set on JVM's > > -server -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx768m -Xms768m > -XX:MaxNewSize=500m -XX:NewSize=500m -XX:+UseParNewGC > -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC > -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=128 > > During our stress test we are seeing that CMS collector is trying to > start old gen collection very frequently and the cpu usage spikes upto > 99% -100% usage. > Our stress test included adding a user per second until we reach 2500 > user limit and then we maintain steady user rate of 2500. > > Attached are the gc logs from one of the JVM, the PrintGCStats details > and GCTimeline graph from GCHisto tool > > Is there anything I should set so that CMS collector doesn't start so > frequently. Also, don't know if increasing the total heap size (to > 1GB) will improve this situation. > > Please provide your comments. > > thanks > vasu.. > > > ------------------------------------------------------------------------ > Windows Live?: Life without walls. Check it out. > > > >------------------------------------------------------------------------ > >_______________________________________________ >hotspot-gc-use mailing list >hotspot-gc-use at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Mon Apr 20 20:49:29 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 20 Apr 2009 20:49:29 -0700 Subject: frequent CMS collections/ CPU spike/ Hotspot JRE1.4.2_17/ In-Reply-To: References: <49ED3370.2000701@sun.com> Message-ID: <49ED4249.2090809@sun.com> vasu ts wrote On 04/20/09 20:18,: > Thanks for the reply. > > In our application, we generate lots of objects (xml marshalling and > unmarshalling) which are never re-used. So we thought increasing the > young gen would give enough time for the objects to die young. > What you say is likely true but when the young gen gets collected there has to be space in the tenured gen for anything that survives the young gen collection so you need a tenured gen that also meets the needs of your application. > Also, in the native logs seems like all the young gen is being filled > up and is being collected. Does this mean the young gen should be > allocated more space? ( this will mean the total heap size might have > to increase also). No, the young gen does not necessarily need more space. The way that the GC works is that allocations are done until a generation is full and then a collection is done. Unless you stop doing allocations, you're always going to have the young gen fill up and have to do GC's. > > 9168.037: [GC 9168.038: [ParNew: 504044K->0K(508096K), 0.1534303 secs] > 669773K->196481K(782528K), 0.1547104 secs] > 9168.356: [CMS-concurrent-sweep: 2.269/2.562 secs] > 9168.356: [CMS-concurrent-reset-start] > 9168.766: [CMS-concurrent-reset: 0.409/0.409 secs] > 9170.798: [GC [1 CMS-initial-mark: 193751K(274432K)] 466502K(782528K), > 2.8434545 secs] > 9173.644: [CMS-concurrent-mark-start] > 9176.626: [GC 9176.627: [ParNew: 504111K->0K(508096K), 0.1026683 secs] > 697862K->214832K(782528K), 0.1035612 secs] > 9177.017: [CMS-concurrent-mark: 3.133/3.373 secs] > 9177.017: [CMS-concurrent-preclean-start] > 9177.377: [CMS-concurrent-preclean: 0.319/0.359 secs] > 9177.383: [GC9177.385: [Rescan (parallel) , 0.2564013 secs]9177.641: > [weak refs processing, 0.0331580 secs] [1 CMS-remark: > 214832K(274432K)] 282063K(782528K), 0.2928263 secs] > 9177.679: [CMS-concurrent-sweep-start] > 9178.515: [CMS-concurrent-sweep: 0.835/0.836 secs] > 9178.516: [CMS-concurrent-reset-start] > 9178.623: [CMS-concurrent-reset: 0.107/0.107 secs] > > Will try out your suggestions -XX:MaxTenuringThreshold=15 > -XX:SurvivorRatio=6 or 8. > > vasu.. > > > Date: Mon, 20 Apr 2009 19:46:08 -0700 > > From: Jon.Masamitsu at Sun.COM > > Subject: Re: frequent CMS collections/ CPU spike/ Hotspot JRE1.4.2_17/ > > To: vasu_t_s at hotmail.com > > CC: hotspot-gc-use at openjdk.java.net > > > > With a total heap of 768m and a young gen pf 500m you > > might not have enough room in the tenured (old) gen. > > That is, the amount of free space left in the tenured gen > > may be so small that CMS thinks it need to start > > a collection immediately. Try a larger total heap > > or a smaller yount gen. I see that you're turning on > > > > -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=128 > > > > so everything that survives a young gen is being > > promoted to the tenured gen. Those values reduce > > the CMS pause times but also fill up the tenured > > generation faster. If you don't have a specific reason > > to use those values, 15 for the tenuring threshold and > > 6 or 8 for the survivor ratio may serve you better. > > > > > > > > > > vasu ts wrote On 04/20/09 16:50,: > > > > > Hi all, > > > > > > We have an application which is deployed on IBM websphere 5.1/Solaris > > > 5.9/Sun hotspot JRE1.4.2_17/. We have 4 JVM's which are running on the > > > same machine. > > > These JVM's recieve xml messages from MQ queue which are processed ( > > > business logic stores the data from xml into database) and xml replies > > > are sent back to the MQ queue. > > > > > > Hardware > > > 8 dual core - sparc IV > > > 4 single core - sparc III > > > > > > JRE options set on JVM's > > > > > > -server -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx768m -Xms768m > > > -XX:MaxNewSize=500m -XX:NewSize=500m -XX:+UseParNewGC > > > -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC > > > -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=128 > > > > > > During our stress test we are seeing that CMS collector is trying to > > > start old gen collection very frequently and the cpu usage spikes upto > > > 99% -100% usage. > > > Our stress test included adding a user per second until we reach 2500 > > > user limit and then we maintain steady user rate of 2500. > > > > > > Attached are the gc logs from one of the JVM, the PrintGCStats details > > > and GCTimeline graph from GCHisto tool > > > > > > Is there anything I should set so that CMS collector doesn't start so > > > frequently. Also, don't know if increasing the total heap size (to > > > 1GB) will improve this situation. > > > > > > Please provide your comments. > > > > > > thanks > > > vasu.. > > > > > > > > > > ------------------------------------------------------------------------ > > > Windows Live?: Life without walls. Check it out. > > > > > > > > > > > > > >------------------------------------------------------------------------ > > > > > >_______________________________________________ > > >hotspot-gc-use mailing list > > >hotspot-gc-use at openjdk.java.net > > >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > > > > > > > > > > > ------------------------------------------------------------------------ > Rediscover Hotmail?: Get quick friend updates right in your inbox. > Check it out. > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Igor.Veresov at Sun.COM Thu Apr 23 17:17:01 2009 From: Igor.Veresov at Sun.COM (Igor Veresov) Date: Thu, 23 Apr 2009 17:17:01 -0700 Subject: Request for review(XS): 6819098 G1: reduce RSet scanning times Message-ID: <49F104FD.5080004@sun.com> Modified previous naive work stealing algorithm by introducing a minimal work unit for the helper threads participating in the RSet scan (thus avoiding competition for each card), also added bounded exponential skipping. Testing: JBB2005 on a 16-core intel core2 box with 30G heap (25G young gen), 13 GC threads. The RSet scanning times reduced ~600%. Webrev: http://cr.openjdk.java.net/~iveresov/6819098/webrev.00 From john.coomes at sun.com Thu Apr 23 22:04:04 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Apr 2009 05:04:04 +0000 Subject: hg: jdk7/hotspot-gc: Added tag jdk7-b56 for changeset ba12117a5e6c Message-ID: <20090424050404.45B36E6B2@hg.openjdk.java.net> Changeset: b02d566c15a7 Author: xdono Date: 2009-04-23 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/b02d566c15a7 Added tag jdk7-b56 for changeset ba12117a5e6c ! .hgtags From john.coomes at sun.com Thu Apr 23 22:07:37 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Apr 2009 05:07:37 +0000 Subject: hg: jdk7/hotspot-gc/corba: Added tag jdk7-b56 for changeset 553a664b807b Message-ID: <20090424050739.295D9E6B7@hg.openjdk.java.net> Changeset: aa147fe5f386 Author: xdono Date: 2009-04-23 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/aa147fe5f386 Added tag jdk7-b56 for changeset 553a664b807b ! .hgtags From john.coomes at sun.com Thu Apr 23 22:15:22 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Apr 2009 05:15:22 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: Added tag jdk7-b56 for changeset c197c6801271 Message-ID: <20090424051524.CF5ADE6BC@hg.openjdk.java.net> Changeset: de2086677f62 Author: xdono Date: 2009-04-23 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/de2086677f62 Added tag jdk7-b56 for changeset c197c6801271 ! .hgtags From john.coomes at sun.com Thu Apr 23 22:19:02 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Apr 2009 05:19:02 +0000 Subject: hg: jdk7/hotspot-gc/jaxws: Added tag jdk7-b56 for changeset 0f7fbf85f7a1 Message-ID: <20090424051904.A10CFE6C1@hg.openjdk.java.net> Changeset: 75c6d6edb8b1 Author: xdono Date: 2009-04-23 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxws/rev/75c6d6edb8b1 Added tag jdk7-b56 for changeset 0f7fbf85f7a1 ! .hgtags From john.coomes at sun.com Thu Apr 23 22:23:19 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Apr 2009 05:23:19 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 3 new changesets Message-ID: <20090424052414.00AA3E6C6@hg.openjdk.java.net> Changeset: ffc29fac1330 Author: chegar Date: 2009-04-16 17:42 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ffc29fac1330 4927640: Implementation of the sctp protocol Summary: An implementation-specific API for the Stream Control Transmission Protocol Reviewed-by: alanb, michaelm, jccollet ! make/com/sun/Makefile + make/com/sun/nio/Makefile + make/com/sun/nio/sctp/Exportedfiles.gmk + make/com/sun/nio/sctp/FILES_c.gmk + make/com/sun/nio/sctp/FILES_java.gmk + make/com/sun/nio/sctp/Makefile + make/com/sun/nio/sctp/mapfile-vers ! make/docs/NON_CORE_PKGS.gmk ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris + src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java + src/share/classes/com/sun/nio/sctp/Association.java + src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java + src/share/classes/com/sun/nio/sctp/HandlerResult.java + src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java + src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java + src/share/classes/com/sun/nio/sctp/InvalidStreamException.java + src/share/classes/com/sun/nio/sctp/MessageInfo.java + src/share/classes/com/sun/nio/sctp/Notification.java + src/share/classes/com/sun/nio/sctp/NotificationHandler.java + src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java + src/share/classes/com/sun/nio/sctp/SctpChannel.java + src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java + src/share/classes/com/sun/nio/sctp/SctpServerChannel.java + src/share/classes/com/sun/nio/sctp/SctpSocketOption.java + src/share/classes/com/sun/nio/sctp/SctpStandardSocketOption.java + src/share/classes/com/sun/nio/sctp/SendFailedNotification.java + src/share/classes/com/sun/nio/sctp/ShutdownNotification.java + src/share/classes/com/sun/nio/sctp/package-info.java + src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java + src/share/classes/sun/nio/ch/SctpStdSocketOption.java + src/solaris/classes/sun/nio/ch/SctpAssocChange.java + src/solaris/classes/sun/nio/ch/SctpAssociationImpl.java + src/solaris/classes/sun/nio/ch/SctpChannelImpl.java + src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java + src/solaris/classes/sun/nio/ch/SctpNet.java + src/solaris/classes/sun/nio/ch/SctpNotification.java + src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java + src/solaris/classes/sun/nio/ch/SctpResultContainer.java + src/solaris/classes/sun/nio/ch/SctpSendFailed.java + src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java + src/solaris/classes/sun/nio/ch/SctpShutdown.java + src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java + src/solaris/native/sun/nio/ch/Sctp.h + src/solaris/native/sun/nio/ch/SctpChannelImpl.c + src/solaris/native/sun/nio/ch/SctpNet.c + src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c + src/windows/classes/sun/nio/ch/SctpChannelImpl.java + src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java + src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java + test/com/sun/nio/sctp/MessageInfoTests.java + test/com/sun/nio/sctp/SctpChannel/Bind.java + test/com/sun/nio/sctp/SctpChannel/Connect.java + test/com/sun/nio/sctp/SctpChannel/Receive.java + test/com/sun/nio/sctp/SctpChannel/Send.java + test/com/sun/nio/sctp/SctpChannel/Shutdown.java + test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java + test/com/sun/nio/sctp/SctpChannel/Util.java + test/com/sun/nio/sctp/SctpMultiChannel/Send.java + test/com/sun/nio/sctp/SctpMultiChannel/Util.java + test/com/sun/nio/sctp/SctpServerChannel/Accept.java + test/com/sun/nio/sctp/SctpServerChannel/NonBlockingAccept.java + test/com/sun/nio/sctp/SctpServerChannel/Util.java Changeset: 7fd3bc37afe3 Author: xdono Date: 2009-04-16 19:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7fd3bc37afe3 Merge - src/share/classes/sun/text/normalizer/UProperty.java - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: 38e1121342d8 Author: xdono Date: 2009-04-23 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/38e1121342d8 Added tag jdk7-b56 for changeset 7fd3bc37afe3 ! .hgtags From john.coomes at sun.com Thu Apr 23 22:33:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 24 Apr 2009 05:33:06 +0000 Subject: hg: jdk7/hotspot-gc/langtools: Added tag jdk7-b56 for changeset 825f23a4f262 Message-ID: <20090424053310.84D9BE6CB@hg.openjdk.java.net> Changeset: 4cfd3a840538 Author: xdono Date: 2009-04-23 15:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4cfd3a840538 Added tag jdk7-b56 for changeset 825f23a4f262 ! .hgtags From Y.S.Ramakrishna at Sun.COM Fri Apr 24 02:02:01 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Fri, 24 Apr 2009 02:02:01 -0700 Subject: Troublesome reflection-cached SoftReferences In-Reply-To: <49F17CF0.5070007@sun.com> References: <49F17CF0.5070007@sun.com> Message-ID: <49F18009.4010807@sun.com> Charles Oliver Nutter wrote: > I've run into a case in JRuby where a reflected method is keeping alive > a class, and that class references a large graph of JRuby objects. The > reflected method is off an anonymous interface implementation we create > at runtime. In order for that implementation to construct additional > Ruby objects, it has to reference an instance of our org.jruby.Ruby > class, which in turn references all globally-scoped data, and basically > keeps a lot of stuff alive. > > The SoftReference appears to be part of the root set, and holds only an > array of Constructor objects. Given a bit of time, this reference is > cleared and the graph goes with it. But doing repeated redeploys of a > JRuby application can fill up the heap before those soft references get > a chance to clear. > > So my questions: > > * Is there any way to force the internal reflection caches to flush > themselves? It's very inconvenient that the cache is keeping alive a > class that should be dead. > > * Is there any way to force an early SoftReference cleanup, before their > time has expired? > You can try -XX:SoftRefLRUPolicyMSPerMB=0 , which is kind of a sledgehammer to clear soft refs the first time GC sees them (making them behave, in essence, like weak references) > * Does anyone else find this caching behavior irritating? > The policy is to clear a soft ref if it has not been accessed "recently". The "recency threshold metric" itself is computed as SoftRefLRUPolicyMSPerMB * FreeMemory following last major collection, so that as heap pressure increases we should be clearing soft refs more agressively albeit still in an LRU fashion. Could it be the case that your soft ref is accessed very frequently, so never falls below the computed recency threshold? In any event, the JVM spec guarantees that all soft refs that are not strongly reachable will be cleared before an OOM is issued., I trust your issue is one of performance badness on account of a large heap, not an OOM? thanks. -- ramki > - Charlie > _______________________________________________ > 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 Apr 24 03:04:41 2009 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Fri, 24 Apr 2009 03:04:41 -0700 Subject: Troublesome reflection-cached SoftReferences In-Reply-To: <49F189F5.80606@sun.com> References: <49F17CF0.5070007@sun.com> <49F18009.4010807@sun.com> <49F189F5.80606@sun.com> Message-ID: <49F18EB9.7060309@sun.com> Charles Oliver Nutter wrote: >> In any event, the JVM spec guarantees that all soft refs that are not >> strongly reachable >> will be cleared before an OOM is issued., I trust your issue is one >> of performance badness >> on account of a large heap, not an OOM? > > Actually it is an OOM problem. If it is an OOM problem we can ignore discussion of how to more aggressively clear the soft ref, since that is in some sense moot. > > The problem is that on repeated redeploys, the memory continues to > grow because these SoftReferences are holding on to a large graph of > data. Some of this data holds also to class references, and so rather > than getting a general heap OOM we get a PermGen OOM. Should a PermGen > OOM force softly-reachable objects to be collected as well? > Yes, each and every softly reachable object should be collected before any kind of OOM (whether in perm or in regular heap) is thrown. Have you made sure your soft ref's referent is not strongly reachable? BTW, -XX:+PrintReferenceGC will give some stats on Reference object processing. If you run a debug JVM then -XX:+TraceReferenceGC will give (altogether too much) tracing info as References are processes by GC, -- ramki _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Fri Apr 24 06:31:20 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Fri, 24 Apr 2009 06:31:20 -0700 Subject: Troublesome reflection-cached SoftReferences In-Reply-To: <49F18EB9.7060309@sun.com> References: <49F17CF0.5070007@sun.com> <49F18009.4010807@sun.com> <49F189F5.80606@sun.com> <49F18EB9.7060309@sun.com> Message-ID: <49F1BF28.9060809@sun.com> Y. Srinivas Ramakrishna wrote On 04/24/09 03:04,: >Charles Oliver Nutter wrote: > > >>>In any event, the JVM spec guarantees that all soft refs that are not >>>strongly reachable >>>will be cleared before an OOM is issued., I trust your issue is one >>>of performance badness >>>on account of a large heap, not an OOM? >>> >>> >>Actually it is an OOM problem. >> >> > >If it is an OOM problem we can ignore discussion of how to more >aggressively clear the soft ref, since that is >in some sense moot. > > Which garbage collector and which jdk release are you using? _______________________________________________ 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 Fri Apr 24 08:42:49 2009 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Fri, 24 Apr 2009 08:42:49 -0700 Subject: Troublesome reflection-cached SoftReferences In-Reply-To: <49F17CF0.5070007@sun.com> References: <49F17CF0.5070007@sun.com> Message-ID: <49F1DDF9.9080506@Sun.COM> Charles Oliver Nutter wrote: > I've run into a case in JRuby where a reflected method is keeping alive > a class, and that class references a large graph of JRuby objects. The > reflected method is off an anonymous interface implementation we create > at runtime. In order for that implementation to construct additional > Ruby objects, it has to reference an instance of our org.jruby.Ruby > class, which in turn references all globally-scoped data, and basically > keeps a lot of stuff alive. > > The SoftReference appears to be part of the root set, and holds only an > array of Constructor objects. Given a bit of time, this reference is > cleared and the graph goes with it. But doing repeated redeploys of a > JRuby application can fill up the heap before those soft references get > a chance to clear. > > So my questions: > > * Is there any way to force the internal reflection caches to flush > themselves? It's very inconvenient that the cache is keeping alive a > class that should be dead. > > * Is there any way to force an early SoftReference cleanup, before their > time has expired? If you can get to the SoftReference objects, you can call java.lang.ref.Reference.clear() on them. That way they won't hold on to their referent until the SoftReference policy clears them. I'm with Ramki though: all the SoftReferences should be cleared by the collector before it throws OOME at you. ... peter > * Does anyone else find this caching behavior irritating? > > - Charlie > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Fri Apr 24 11:50:25 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Fri, 24 Apr 2009 11:50:25 -0700 Subject: Troublesome reflection-cached SoftReferences In-Reply-To: <49F1C683.8000204@sun.com> References: <49F17CF0.5070007@sun.com> <49F18009.4010807@sun.com> <49F189F5.80606@sun.com> <49F18EB9.7060309@sun.com> <49F1BF28.9060809@sun.com> <49F1C683.8000204@sun.com> Message-ID: <49F209F1.7020505@sun.com> Charles Oliver Nutter wrote On 04/24/09 07:02,: >Jon Masamitsu wrote: > > >>Which garbage collector and which jdk release are you using? >> >> > >Java HotSpot(TM) 64-Bit Server VM version 1.6.0_07-b06-57 > >Garbage collector: Name = 'Copy' >Garbage collector: Name = 'MarkSweepCompact' > > I'm don't know how Apple has set it's defaults and the names above are not specific enough. Can you run the command java -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -version You should get output such as java -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -version -XX:MaxHeapSize=1073741824 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseParallelGC java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode) Heap PSYoungGen total 12544K, used 215K [0xf4000000, 0xf4e00000, 0xfb200000) eden space 10752K, 2% used [0xf4000000,0xf4035c38,0xf4a80000) from space 1792K, 0% used [0xf4c40000,0xf4c40000,0xf4e00000) to space 1792K, 0% used [0xf4a80000,0xf4a80000,0xf4c40000) PSOldGen total 110592K, used 0K [0xbb000000, 0xc1c00000, 0xf4000000) object space 110592K, 0% used [0xbb000000,0xbb000000,0xc1c00000) PSPermGen total 16384K, used 1449K [0xb7000000, 0xb8000000, 0xbb000000) object space 16384K, 8% used [0xb7000000,0xb716a5b8,0xb8000000) This will tell us exactly what is being run. >These are the defaults running on Mac. Yes, this is the Apple JDK, but >we've reproduces these issues under Sun/OpenJDK as well. I'm really just >trying to figure out *why* all this stuff is sticking around, and the >soft reference has been my first solid lead. > >- Charlie >_______________________________________________ >hotspot-gc-use mailing list >hotspot-gc-use at openjdk.java.net >http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Sun Apr 26 22:47:25 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Sun, 26 Apr 2009 22:47:25 -0700 Subject: concurrent mode failure in minor gc/ -XX:CMSFullGCsBeforeCompaction=1 In-Reply-To: References: <49ED3370.2000701@sun.com> <49ED4249.2090809@sun.com> Message-ID: <49F546ED.3030700@sun.com> The behavior of CMS with regard to concurrent mode failures has changed quite a bit since 1.4.2. Since this is a mailing list for the open source jdk (currently jdk7), you might get better 1.4.2 info from your Sun support. vasu ts wrote On 04/25/09 06:21,: > Hi all, > > We have an application which is deployed on IBM websphere 5.1/Solaris > 5.9/Sun hotspot JRE1.4.2_17/. We have 4 JVM's which are running on the > same machine. These JVM's recieve xml messages from MQ queue which are > processed ( business logic stores the data from xml into database) and > xml replies are sent back to the MQ queue. In our application, we > generate lots of objects (xml marshalling and unmarshalling) which are > never re-used.Our goal is to sustain the application for 24 hrs with a > steady load of 2500 users. > > Hardware > 8 dual core - sparc IV > 4 single core - sparc III > > > 1) > > Options used : > -server -Xmx768m -Xms768m -XX:MaxNewSize=256m -XX:NewSize=256m > -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC > -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly > > We did the stress test with -XX:CMSInitiatingOccupancyFraction=60 flag > and what we saw was that initially, CMS collector was adhering to the > setting and was starting a full GC, when old gen is 60% full. But when > we reach the steady load of 2500 users seems like CMS collector cannot > keep up with allocation rate and thus it cannot do a Full GC, when it > is 60% full. See attached excel which shows how much old gen % was > filled up. Also, I have attached the native logs > (native_stdout_option_1.log) from this test. > > Once the old gen is 94% full, there is a concurrent mode failure which > results in a compaction which takes 21.2 secs. Please note we saw CPU > spikes (80-99% usage) when the old gen was filling up. We did not > continue the test further because we thought we will eventually end up > with the several compactions over a period of time. > > 2) > > Options used: > -server -Xmx768m -Xms768m -XX:MaxNewSize=256m -XX:NewSize=256m > -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC > -XX:CMSInitiatingOccupancyFraction=60 > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=1 > > To reduce the compactions we added -XX:CMSFullGCsBeforeCompaction=1 > and tested our application again. We saw that there were several > "concurrent mode failure" when minor collections were happening. Any > ideas?, why this is happening so early into the test (23 secs into the > test). See below snapshot from the native logs. Also, I see that the > survivor ratio is only being set to 192K , Is this the default size > with CMS collector?. Next week, we will see if increasing the heap > size and tweaking the survivor ratio helps the application. > > thanks > vasu.. > > > 23.144: [GC {Heap before GC invocations=0: > Heap > par new generation total 261952K, used 261754K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 99% used [0xc4800000, 0xd479eb68, 0xd47a0000) > from space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > to space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > concurrent mark-sweep generation total 524288K, used 0K [0xd4800000, > 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 28544K, used 28479K [0xf4800000, > 0xf63e0000, 0xf8800000) > 23.147: [ParNew: 261754K->0K(261952K), 0.1828999 secs] > 261754K->9956K(786240K) Heap after GC invocations=1: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 9956K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 28544K, used 28479K [0xf4800000, > 0xf63e0000, 0xf8800000) > } , 0.1843301 secs] > 34.492: [GC {Heap before GC invocations=1: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 9956K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 35200K, used 35085K [0xf4800000, > 0xf6a60000, 0xf8800000) > 34.492: [ParNew: 261760K->261760K(261952K), 0.0001138 secs]34.493: > [CMS (concurrent mode failure)[Unloading class > com.ibm.ws.Transaction.JTA.XARecUtil] > : 9956K->17291K(524288K), 2.1463156 secs] 271716K->17291K(786240K) > Heap after GC invocations=2: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 17291K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 35200K, used 35023K [0xf4800000, > 0xf6a60000, 0xf8800000) > } , 2.1476960 secs] > 495.514: [GC {Heap before GC invocations=2: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 17291K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36096K, used 35999K [0xf4800000, > 0xf6b40000, 0xf8800000) > 495.515: [ParNew: 261760K->261760K(261952K), 0.0001167 secs]495.515: > [CMS (concurrent mode failure): 17291K->20296K(524288K), 1.7551403 > secs] 279051K->20296K(786240K) Heap after GC invocations=3: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 20296K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36096K, used 35983K [0xf4800000, > 0xf6b40000, 0xf8800000) > } , 1.7565744 secs] > 660.887: [GC {Heap before GC invocations=3: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 20296K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36992K, used 36930K [0xf4800000, > 0xf6c20000, 0xf8800000) > 660.888: [ParNew: 261760K->261760K(261952K), 0.0001172 secs]660.888: > [CMS (concurrent mode failure): 20296K->23930K(524288K), 1.9326939 > secs] 282056K->23930K(786240K) Heap after GC invocations=4: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23930K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36992K, used 36908K [0xf4800000, > 0xf6c20000, 0xf8800000) > } , 1.9341771 secs] > 755.905: [GC {Heap before GC invocations=4: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23930K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38528K, used 38413K [0xf4800000, > 0xf6da0000, 0xf8800000) > 755.906: [ParNew: 261760K->261760K(261952K), 0.0001159 secs]755.906: > [CMS (concurrent mode failure): 23930K->23518K(524288K), 1.9600006 > secs] 285690K->23518K(786240K) Heap after GC invocations=5: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23518K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38528K, used 38377K [0xf4800000, > 0xf6da0000, 0xf8800000) > } , 1.9614396 secs] > 832.698: [GC {Heap before GC invocations=5: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23518K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38633K [0xf4800000, > 0xf6de0000, 0xf8800000) > 832.699: [ParNew: 261760K->261760K(261952K), 0.0001141 secs]832.699: > [CMS (concurrent mode failure)[Unloading class > sun.reflect.GeneratedSerializationConstructorAccessor1] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor22] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor21] > : 23518K->22650K(524288K), 2.0814234 secs] 285278K->22650K(786240K) > Heap after GC invocations=6: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 22650K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38563K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 2.0828510 secs] > 900.246: [GC {Heap before GC invocations=6: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 22650K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38664K [0xf4800000, > 0xf6de0000, 0xf8800000) > 900.247: [ParNew: 261760K->261760K(261952K), 0.0001151 secs]900.247: > [CMS (concurrent mode failure)[Unloading class > sun.reflect.GeneratedSerializationConstructorAccessor15] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor40] > [Unloading class sun.reflect.GeneratedMethodAccessor2] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor36] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor20] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor34] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor31] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor29] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor16] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor13] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor39] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor27] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor32] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor67] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor10] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor35] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor17] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor11] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor26] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor18] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor38] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor33] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor25] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor6] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor7] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor37] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor9] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor8] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor4] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor42] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor30] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor3] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor14] > : 22650K->21627K(524288K), 2.0554604 secs] 284410K->21627K(786240K) > Heap after GC invocations=7: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21627K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38530K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 2.0569150 secs] > 973.776: [GC {Heap before GC invocations=7: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21627K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38606K [0xf4800000, > 0xf6de0000, 0xf8800000) > 973.777: [ParNew: 261760K->261760K(261952K), 0.0001188 secs]973.777: > [CMS (concurrent mode failure): 21627K->21663K(524288K), 1.9085358 > secs] 283387K->21663K(786240K) Heap after GC invocations=8: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21663K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38573K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 1.9100083 secs] > 1044.718: [GC {Heap before GC invocations=8: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21663K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38647K [0xf4800000, > 0xf6de0000, 0xf8800000) > 1044.719: [ParNew: 261760K->261760K(261952K), 0.0001185 secs]1044.719: > [CMS (concurrent mode failure): 21663K->21546K(524288K), 1.8343919 > secs] 283423K->21546K(786240K) Heap after GC invocations=9: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21546K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38615K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 1.8358148 secs] > 1115.795: [GC {Heap before GC invocations=9: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21546K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38701K [0xf4800000, > 0xf6de0000, 0xf8800000) > 1115.795: [ParNew: 261760K->261760K(261952K), 0.0001158 secs]1115.796: > [CMS (concurrent mode failure): 21546K->20650K(524288K), 1.8198966 > secs] 283306K->20650K(786240K) Heap after GC invocations=10: > primadm at condo102# head -200 native_stdout.log |more > 23.144: [GC {Heap before GC invocations=0: > Heap > par new generation total 261952K, used 261754K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 99% used [0xc4800000, 0xd479eb68, 0xd47a0000) > from space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > to space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > concurrent mark-sweep generation total 524288K, used 0K [0xd4800000, > 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 28544K, used 28479K [0xf4800000, > 0xf63e0000, 0xf8800000) > 23.147: [ParNew: 261754K->0K(261952K), 0.1828999 secs] > 261754K->9956K(786240K) Heap after GC invoca > tions=1: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 9956K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 28544K, used 28479K [0xf4800000, > 0xf63e0000, 0xf8800000) > } , 0.1843301 secs] > 34.492: [GC {Heap before GC invocations=1: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 9956K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 35200K, used 35085K [0xf4800000, > 0xf6a60000, 0xf8800000) > 34.492: [ParNew: 261760K->261760K(261952K), 0.0001138 secs]34.493: > [CMS (concurrent mode failure)[U > nloading class com.ibm.ws.Transaction.JTA.XARecUtil] > : 9956K->17291K(524288K), 2.1463156 secs] 271716K->17291K(786240K) > Heap after GC invocations=2: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 17291K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 35200K, used 35023K [0xf4800000, > 0xf6a60000, 0xf8800000) > } , 2.1476960 secs] > 495.514: [GC {Heap before GC invocations=2: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 17291K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36096K, used 35999K [0xf4800000, > 0xf6b40000, 0xf8800000) > 495.515: [ParNew: 261760K->261760K(261952K), 0.0001167 secs]495.515: > [CMS (concurrent mode failure) > : 17291K->20296K(524288K), 1.7551403 secs] 279051K->20296K(786240K) > Heap after GC invocations=3: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 20296K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36096K, used 35983K [0xf4800000, > 0xf6b40000, 0xf8800000) > } , 1.7565744 secs] > 660.887: [GC {Heap before GC invocations=3: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 20296K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36992K, used 36930K [0xf4800000, > 0xf6c20000, 0xf8800000) > 660.888: [ParNew: 261760K->261760K(261952K), 0.0001172 secs]660.888: > [CMS (concurrent mode failure) > : 20296K->23930K(524288K), 1.9326939 secs] 282056K->23930K(786240K) > Heap after GC invocations=4: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23930K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 36992K, used 36908K [0xf4800000, > 0xf6c20000, 0xf8800000) > } , 1.9341771 secs] > 755.905: [GC {Heap before GC invocations=4: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23930K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38528K, used 38413K [0xf4800000, > 0xf6da0000, 0xf8800000) > 755.906: [ParNew: 261760K->261760K(261952K), 0.0001159 secs]755.906: > [CMS (concurrent mode failure) > : 23930K->23518K(524288K), 1.9600006 secs] 285690K->23518K(786240K) > Heap after GC invocations=5: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23518K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38528K, used 38377K [0xf4800000, > 0xf6da0000, 0xf8800000) > } , 1.9614396 secs] > 832.698: [GC {Heap before GC invocations=5: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 23518K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38633K [0xf4800000, > 0xf6de0000, 0xf8800000) > 832.699: [ParNew: 261760K->261760K(261952K), 0.0001141 secs]832.699: > [CMS (concurrent mode failure) > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor1] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor22] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor21] > : 23518K->22650K(524288K), 2.0814234 secs] 285278K->22650K(786240K) > Heap after GC invocations=6: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 22650K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38563K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 2.0828510 secs] > 900.246: [GC {Heap before GC invocations=6: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 22650K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38664K [0xf4800000, > 0xf6de0000, 0xf8800000) > 900.247: [ParNew: 261760K->261760K(261952K), 0.0001151 secs]900.247: > [CMS (concurrent mode failure) > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor15] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor40] > [Unloading class sun.reflect.GeneratedMethodAccessor2] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor36] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor20] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor34] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor31] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor29] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor16] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor13] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor39] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor27] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor32] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor67] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor10] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor35] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor17] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor11] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor26] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor18] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor38] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor33] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor25] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor6] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor7] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor37] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor9] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor8] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor4] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor42] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor30] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor3] > [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor14] > : 22650K->21627K(524288K), 2.0554604 secs] 284410K->21627K(786240K) > Heap after GC invocations=7: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21627K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38530K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 2.0569150 secs] > 973.776: [GC {Heap before GC invocations=7: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21627K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38606K [0xf4800000, > 0xf6de0000, 0xf8800000) > 973.777: [ParNew: 261760K->261760K(261952K), 0.0001188 secs]973.777: > [CMS (concurrent mode failure) > : 21627K->21663K(524288K), 1.9085358 secs] 283387K->21663K(786240K) > Heap after GC invocations=8: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21663K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38573K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 1.9100083 secs] > 1044.718: [GC {Heap before GC invocations=8: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21663K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38647K [0xf4800000, > 0xf6de0000, 0xf8800000) > 1044.719: [ParNew: 261760K->261760K(261952K), 0.0001185 secs]1044.719: > [CMS (concurrent mode failur > e): 21663K->21546K(524288K), 1.8343919 secs] 283423K->21546K(786240K) > Heap after GC invocations=9: > Heap > par new generation total 261952K, used 0K [0xc4800000, 0xd4800000, > 0xd4800000) > eden space 261760K, 0% used [0xc4800000, 0xc4800000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21546K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38615K [0xf4800000, > 0xf6de0000, 0xf8800000) > } , 1.8358148 secs] > 1115.795: [GC {Heap before GC invocations=9: > Heap > par new generation total 261952K, used 261760K [0xc4800000, > 0xd4800000, 0xd4800000) > eden space 261760K, 100% used [0xc4800000, 0xd47a0000, 0xd47a0000) > from space 192K, 0% used [0xd47d0000, 0xd47d0000, 0xd4800000) > to space 192K, 0% used [0xd47a0000, 0xd47a0000, 0xd47d0000) > concurrent mark-sweep generation total 524288K, used 21546K > [0xd4800000, 0xf4800000, 0xf4800000) > concurrent-mark-sweep perm gen total 38784K, used 38701K [0xf4800000, > 0xf6de0000, 0xf8800000) > 1115.795: [ParNew: 261760K->261760K(261952K), 0.0001158 secs]1115.796: > [CMS (concurrent mode failur > e): 21546K->20650K(524288K), 1.8198966 secs] 283306K->20650K(786240K) > Heap after GC invocations=10: > > > > > ------------------------------------------------------------------------ > Windows Live? SkyDrive?: Get 25 GB of free online storage. Check it > out. > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Mon Apr 27 09:13:48 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 27 Apr 2009 09:13:48 -0700 Subject: concurrent mode failure in minor gc/ -XX:CMSFullGCsBeforeCompaction=1 In-Reply-To: <49F546ED.3030700@sun.com> References: <49ED3370.2000701@sun.com> <49ED4249.2090809@sun.com> <49F546ED.3030700@sun.com> Message-ID: <49F5D9BC.8090806@Sun.COM> What Jon said re contacting Sun support etc. One important thing we have learned about CMS is that the filtering of short-lived objects in the young gen is important both for relieving short-term pressure on the CMS collector and in the long-term for reducing fragmentation of the old gen, either or both of which might otherwise cause concurrent mode failure. I have never myself found CMSFullGCsBeforeCompaction != 0 to be particularly useful as a tuning knob. regards. -- ramki >> 1) >> >> Options used : >> -server -Xmx768m -Xms768m -XX:MaxNewSize=256m -XX:NewSize=256m >> -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC >> -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly >> ... >> >> 2) >> >> Options used: >> -server -Xmx768m -Xms768m -XX:MaxNewSize=256m -XX:NewSize=256m >> -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC >> -XX:CMSInitiatingOccupancyFraction=60 >> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=1 >> ... > > > _______________________________________________ > 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 Mon Apr 27 09:17:03 2009 From: Y.S.Ramakrishna at Sun.COM (Y.S.Ramakrishna at Sun.COM) Date: Mon, 27 Apr 2009 09:17:03 -0700 Subject: concurrent mode failure in minor gc/ -XX:CMSFullGCsBeforeCompaction=1 In-Reply-To: <49F5D9BC.8090806@Sun.COM> References: <49ED3370.2000701@sun.com> <49ED4249.2090809@sun.com> <49F546ED.3030700@sun.com> <49F5D9BC.8090806@Sun.COM> Message-ID: <49F5DA7F.3040105@Sun.COM> > One important thing we have learned about CMS is > that the filtering of short-lived objects in the young gen is > important both for relieving short-term pressure on the CMS collector > and in the long-term for reducing fragmentation of the old > gen, either or both of which might otherwise cause concurrent mode failure. Rereading that, I see that it was too cryptic. What I meant was that use of the survivor spaces (and at _last_ a tenuring threshold of 1, if not higher -- use PrintTenuringDistribution to tune an optimum) is crucial to getting good performance out of CMS. - ramki _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From Jon.Masamitsu at Sun.COM Mon Apr 27 10:30:02 2009 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 27 Apr 2009 10:30:02 -0700 Subject: concurrent mode failure in minor gc/ -XX:CMSFullGCsBeforeCompaction=1 In-Reply-To: <49F5DA7F.3040105@Sun.COM> References: <49ED3370.2000701@sun.com> <49ED4249.2090809@sun.com> <49F546ED.3030700@sun.com> <49F5D9BC.8090806@Sun.COM> <49F5DA7F.3040105@Sun.COM> Message-ID: <49F5EB9A.5060103@sun.com> Ramki's mail reminded me that you might find these useful if you have not already seen them. http://blogs.sun.com/jonthecollector/entry/the_fault_with_defaults http://blogs.sun.com/jonthecollector/entry/what_the_heck_s_a Y.S.Ramakrishna at Sun.COM wrote On 04/27/09 09:17,: >>One important thing we have learned about CMS is >>that the filtering of short-lived objects in the young gen is >>important both for relieving short-term pressure on the CMS collector >>and in the long-term for reducing fragmentation of the old >>gen, either or both of which might otherwise cause concurrent mode failure. >> >> > >Rereading that, I see that it was too cryptic. What I meant was >that use of the survivor spaces (and at _last_ a tenuring threshold of >1, if not higher -- use PrintTenuringDistribution to tune an optimum) >is crucial to getting good performance out of CMS. > >- ramki >_______________________________________________ >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 antonios.printezis at sun.com Mon Apr 27 12:10:33 2009 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Mon, 27 Apr 2009 19:10:33 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6829013: G1: set the default value of G1VerifyConcMarkPrintRechable to false Message-ID: <20090427191039.08822E8C9@hg.openjdk.java.net> Changeset: 2b6c55e36143 Author: tonyp Date: 2009-04-23 16:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2b6c55e36143 6829013: G1: set the default value of G1VerifyConcMarkPrintRechable to false Summary: Turn off G1VerifyConcMarkPrintReachable by default to minimize the amount of verbose output we generate by default. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp From andrey.petrusenko at sun.com Mon Apr 27 16:19:03 2009 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 27 Apr 2009 23:19:03 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 21 new changesets Message-ID: <20090427231947.C1C56E92E@hg.openjdk.java.net> Changeset: f8e839c08615 Author: xdono Date: 2009-04-09 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/f8e839c08615 Added tag jdk7-b54 for changeset fafab5d5349c ! .hgtags Changeset: bcbec53c367d Author: xdono Date: 2009-04-16 11:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bcbec53c367d Added tag jdk7-b55 for changeset f8e839c08615 ! .hgtags Changeset: a3fd9e40ff2e Author: trims Date: 2009-04-21 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a3fd9e40ff2e Merge Changeset: c8152ae3f339 Author: coleenp Date: 2009-04-21 16:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c8152ae3f339 6830069: UseLargePages is broken on Win64 Summary: Making VirtualAlloc/VirtualProtect two calls for PAGE_EXECUTE_READWRITE doesn't work for MEM_LARGE_PAGES. Reviewed-by: xlu, kvn, jcoomes ! src/os/windows/vm/os_windows.cpp Changeset: 670013185256 Author: xlu Date: 2009-04-22 11:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/670013185256 Merge Changeset: a61730a6fdbc Author: trims Date: 2009-04-22 19:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a61730a6fdbc 6833316: jprt.properties not setting values for 6u14 release flag Summary: Fix jprt.properties to do 6u14 tests right Reviewed-by: ohair ! make/jprt.properties Changeset: 67a2f5ba5582 Author: never Date: 2009-04-15 09:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/67a2f5ba5582 6684007: PrintAssembly plugin not available for linux or windows Reviewed-by: rasbold, jrose, twisti ! .hgignore ! make/windows/makefiles/vm.make ! src/share/tools/MakeDeps/BuildConfig.java ! src/share/tools/hsdis/Makefile ! src/share/tools/hsdis/README ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c Changeset: 1b42d5772ae0 Author: never Date: 2009-04-16 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/1b42d5772ae0 6449385: JCK test dup2_x200106m1 fails with Segmentation Fault on x86 Reviewed-by: kvn ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp Changeset: a134d9824964 Author: never Date: 2009-04-16 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/a134d9824964 6828024: verification of fixed interval usage is too weak Reviewed-by: kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/includeDB_compiler1 Changeset: 3ec1ff9307d6 Author: never Date: 2009-04-16 21:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3ec1ff9307d6 6741757: minor ctw improvements Reviewed-by: kvn ! src/share/vm/classfile/classLoader.cpp Changeset: 2bf529ef0adb Author: kvn Date: 2009-04-17 09:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2bf529ef0adb 6831323: Use v8plus as minimum required hardware for current Hotspot sources Summary: Use -xarch=v8plus as default for 32-bits VM on sparc. Reviewed-by: never, twisti ! make/solaris/makefiles/sparcWorks.make Changeset: 928912ce8438 Author: never Date: 2009-04-20 14:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/928912ce8438 Merge Changeset: be93aad57795 Author: jrose Date: 2009-04-21 23:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/be93aad57795 6655646: dynamic languages need dynamically linked call sites Summary: invokedynamic instruction (JSR 292 RI) Reviewed-by: twisti, never ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/includeDB_jvmti ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 6b2273dd6fa9 Author: twisti Date: 2009-04-21 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6b2273dd6fa9 6822110: Add AddressLiteral class on SPARC Summary: The Address class on SPARC currently handles both, addresses and address literals, what makes the Address class more complicated than it has to be. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp Changeset: 85656c8fa13f Author: twisti Date: 2009-04-22 06:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/85656c8fa13f Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 04fa5affa478 Author: kvn Date: 2009-04-22 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/04fa5affa478 6709742: find_base_for_derived's use of Ideal NULL is unsafe causing crashes during register allocation Summary: Create a mach node corresponding to ideal node ConP #NULL specifically for derived pointers. Reviewed-by: never ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp Changeset: 9c6be3edf0dc Author: cfang Date: 2009-04-23 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9c6be3edf0dc 6589834: deoptimization problem with -XX:+DeoptimizeALot Summary: Relocate the stack pointer adjustment to where uncommon_trap is actually inserted for new_array. Reviewed-by: kvn, jrose ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp + test/compiler/6589834/Test_ia32.java Changeset: aa92a90b1cc6 Author: cfang Date: 2009-04-24 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/aa92a90b1cc6 6833951: Extra ":" Causes Testcase in CR 6589834 "Parse Exception: Invalid tag: summary:" Summary: Remove the colon Reviewed-by: never ! test/compiler/6589834/Test_ia32.java Changeset: fb4c18a2ec66 Author: never Date: 2009-04-24 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fb4c18a2ec66 6833573: C2 sparc: assert(c < 64 && (c & 1) == 0,"bad double float register") Reviewed-by: twisti ! src/cpu/sparc/vm/sparc.ad Changeset: 6ffcd0923239 Author: never Date: 2009-04-24 18:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6ffcd0923239 Merge Changeset: 4753e4079a5a Author: apetrusenko Date: 2009-04-27 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4753e4079a5a Merge From igor.veresov at sun.com Mon Apr 27 20:44:10 2009 From: igor.veresov at sun.com (igor.veresov at sun.com) Date: Tue, 28 Apr 2009 03:44:10 +0000 Subject: hg: jdk7/hotspot-gc/hotspot: 6819098: G1: reduce RSet scanning times Message-ID: <20090428034416.10992E954@hg.openjdk.java.net> Changeset: b803b1b9e206 Author: iveresov Date: 2009-04-27 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/b803b1b9e206 6819098: G1: reduce RSet scanning times Summary: Added a feedback-driven exponential skipping for parallel RSet scanning. Reviewed-by: tonyp, apetrusenko ! src/share/vm/gc_implementation/g1/g1RemSet.cpp From john.coomes at sun.com Thu Apr 30 22:34:20 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 01 May 2009 05:34:20 +0000 Subject: hg: jdk7/hotspot-gc: 5 new changesets Message-ID: <20090501053421.15CD7ED15@hg.openjdk.java.net> Changeset: e13a01c44efe Author: ohair Date: 2009-04-27 20:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/e13a01c44efe 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell - make/jprt.config ! make/jprt.properties Changeset: caba6a812b19 Author: peterz Date: 2009-04-25 21:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/caba6a812b19 6591875: Nimbus Swing Look and Feel Reviewed-by: jasper, ohair ! README-builds.html Changeset: 8f5674f7087d Author: yan Date: 2009-04-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/8f5674f7087d Merge Changeset: ffd09e767dfa Author: yan Date: 2009-04-29 00:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/ffd09e767dfa Merge Changeset: 59b497130f82 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/rev/59b497130f82 Added tag jdk7-b57 for changeset ffd09e767dfa ! .hgtags From john.coomes at sun.com Thu Apr 30 22:38:06 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 01 May 2009 05:38:06 +0000 Subject: hg: jdk7/hotspot-gc/corba: 4 new changesets Message-ID: <20090501053810.C8608ED1A@hg.openjdk.java.net> Changeset: 4906dae0c5fa Author: tbell Date: 2009-04-20 00:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/4906dae0c5fa 6372405: Server thread hangs when fragments don't complete because of connection abort 5104239: Java: thread deadlock 6191561: JCK15: api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods sometime hang 6486322: org.omg.CORBA.ORB.init() thread safety issue 6420980: Security issue with the com.sun.corba.se.impl.orbutil.ORBUtility class 6465377: NullPointerException for RMI ORB in 1.5.0_08 6553303: Corba application fails w/ org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: No 6438259: Wrong repository ID generated by IDLJ Reviewed-by: darcy ! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerReadStream.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAFactory.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBSingleton.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java ! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/tools/corba/se/idl/Parser.java ! src/share/classes/com/sun/tools/corba/se/logutil/InputException.java ! src/share/classes/org/omg/CORBA/ORB.java Changeset: 1c55bc99d36c Author: tbell Date: 2009-04-23 21:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/1c55bc99d36c Merge Changeset: 972c6157fae5 Author: ohair Date: 2009-04-27 20:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/972c6157fae5 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell - make/jprt.config ! make/jprt.properties Changeset: 080ecdea3020 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/corba/rev/080ecdea3020 Added tag jdk7-b57 for changeset 972c6157fae5 ! .hgtags From john.coomes at sun.com Thu Apr 30 22:46:36 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 01 May 2009 05:46:36 +0000 Subject: hg: jdk7/hotspot-gc/jaxp: 5 new changesets Message-ID: <20090501054644.C55E5ED1F@hg.openjdk.java.net> Changeset: b56d870cb5c8 Author: tbell Date: 2009-04-20 22:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/b56d870cb5c8 6738894: Merge jaxp fixes from 6 update train into OpenJDK 6 and 7 6573268: Four JCK-devtools-6a tests report OOM: Java Heap space since JDK7 b14 Reviewed-by: darcy ! .hgignore ! THIRD_PARTY_README + TRADEMARK ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Type.java ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/dom/EntityImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties ! src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/share/classes/com/sun/org/apache/xml/internal/utils/ThreadControllerWrapper.java ! src/share/classes/com/sun/org/apache/xpath/internal/axes/NodeSequence.java ! src/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java Changeset: ee3d2d2bec61 Author: tbell Date: 2009-04-20 22:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/ee3d2d2bec61 Merge - make/jprt.config Changeset: 4f6b0a4d3768 Author: tbell Date: 2009-04-23 21:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/4f6b0a4d3768 Merge Changeset: e4851e9f7be2 Author: ohair Date: 2009-04-27 20:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/e4851e9f7be2 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties Changeset: fb846b3f9450 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jaxp/rev/fb846b3f9450 Added tag jdk7-b57 for changeset e4851e9f7be2 ! .hgtags From john.coomes at sun.com Thu Apr 30 22:58:03 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 01 May 2009 05:58:03 +0000 Subject: hg: jdk7/hotspot-gc/jdk: 79 new changesets Message-ID: <20090501061622.35FB9ED29@hg.openjdk.java.net> Changeset: a31f5f824580 Author: weijun Date: 2009-04-08 13:54 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a31f5f824580 4811968: ASN.1 (X509Certificate) implementations don't handle large OID components Reviewed-by: xuelei ! src/share/classes/sun/security/util/ObjectIdentifier.java ! test/sun/security/util/Oid/OidFormat.java + test/sun/security/util/Oid/S11N.sh + test/sun/security/util/Oid/SerialTest.java Changeset: 74a3d8978eb0 Author: sherman Date: 2009-04-08 09:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/74a3d8978eb0 6827871: Cleanup leftover code in CharToByteJohab.java Summary: Removed the leftover data tables Reviewed-by: alanb ! src/share/classes/sun/io/CharToByteJohab.java Changeset: 6fe0aa207f5f Author: sherman Date: 2009-04-08 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6fe0aa207f5f 6827921: ByteToCharBig5.java should use nio data tables instead of its own copy Summary: To use the data tables from sun.nio.cs.ext.Big5 Reviewed-by: alanb ! src/share/classes/sun/io/ByteToCharBig5.java Changeset: 8d37331265ae Author: weijun Date: 2009-04-09 15:32 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8d37331265ae 6714845: Quotes in Kerberos configuration file are included in the values Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Config.java + test/sun/security/krb5/ConfigWithQuotations.java + test/sun/security/krb5/edu.mit.Kerberos Changeset: 897b2d42995a Author: weijun Date: 2009-04-10 11:21 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/897b2d42995a 6587676: Krb5LoginModule failure if useTicketCache=true on Vista Reviewed-by: valeriep ! src/windows/native/sun/security/krb5/NativeCreds.c Changeset: 572d3f36c8a9 Author: martin Date: 2009-04-12 20:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/572d3f36c8a9 6827153: Miscellaneous typos in javadoc Reviewed-by: alanb ! src/share/classes/java/lang/NoSuchFieldError.java ! src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParametersSpi.java ! src/share/classes/java/security/PrivilegedActionException.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java ! src/share/classes/java/security/SignatureSpi.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java Changeset: 6f99dbd58123 Author: valeriep Date: 2009-04-13 18:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6f99dbd58123 6829098: Regression test java/security/Security/ClassLoaderDeadlock/Deadlock2.java error - missing ";" Summary: Added back the missing ";" Reviewed-by: weijun ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.java Changeset: 33e06332c9d4 Author: weijun Date: 2009-04-16 11:16 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/33e06332c9d4 6830658: Changeset 897b2d42995a breaks the fastdebug build in NativeCreds.c Reviewed-by: tbell ! src/windows/native/sun/security/krb5/NativeCreds.c Changeset: 1aaeb8fbe705 Author: sherman Date: 2009-04-16 21:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/1aaeb8fbe705 4244499: ZipEntry() does not convert filenames from Unicode to platform 4532049: IllegalArgumentException in ZipInputStream while reading unicode file 5030283: Incorrect implementation of UTF-8 in zip package 4700978: ZipFile can't treat Japanese name in a zipfile properly 4980042: Cannot use Surrogates in zip file metadata like filenames 4820807: java.util.zip.ZipInputStream cannot extract files with Chinese chars in name Summary: Add new constructors for zip classes to support non-UTF-8 encoded names/comments in ZIP file Reviewed-by: alanb, martin ! make/java/zip/FILES_c.gmk ! make/java/zip/mapfile-vers ! make/java/zip/reorder-i586 ! make/java/zip/reorder-sparc ! make/java/zip/reorder-sparcv9 + src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipConstants64.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/java/util/zip/package.html - src/share/native/java/util/zip/ZipEntry.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h + test/java/util/zip/ZipCoding.java + test/java/util/zip/zip.java Changeset: 0b3660c68262 Author: alanb Date: 2009-04-15 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0b3660c68262 6795561: (bf) CharBuffer.subSequence() uses wrong capacity value for new buffer Reviewed-by: sherman, iris ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! src/share/classes/java/nio/StringCharBuffer.java ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java Changeset: 44b6b2a4dd04 Author: alanb Date: 2009-04-15 16:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/44b6b2a4dd04 6543863: (fc) FileLock.release can deadlock with FileChannel.close 6429910: (fc) FileChannel.lock() IOException: Bad file number, not AsynchronousCloseException 6814948: (fc) test/java/nio/channels/AsynchronousFileChannel/Lock.java failed intermittently 6822643: (fc) AsynchronousFileChannel.close does not invalidate FileLocks Reviewed-by: sherman ! src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/FileLockImpl.java ! src/share/classes/sun/nio/ch/FileLockTable.java ! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/native/sun/nio/ch/FileDispatcherImpl.c ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java + test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java Changeset: ca94dcd8c4fb Author: alanb Date: 2009-04-17 09:38 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ca94dcd8c4fb Merge - src/share/native/java/util/zip/ZipEntry.c Changeset: fb2ccb7c50c7 Author: wetmore Date: 2008-08-22 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/fb2ccb7c50c7 6497740: Limit the size of RSA public keys Reviewed-by: andreas, valeriep, vinnie ! src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/windows/classes/sun/security/mscapi/RSAKeyPairGenerator.java ! src/windows/classes/sun/security/mscapi/RSASignature.java Changeset: 8e51a219fc3b Author: weijun Date: 2008-10-01 10:01 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8e51a219fc3b 6588160: jaas krb5 client leaks OS-level UDP sockets (all platforms) Reviewed-by: jccollet, chegar ! src/share/classes/sun/security/krb5/KrbKdcReq.java ! src/share/classes/sun/security/krb5/internal/UDPClient.java Changeset: 150a441a305d Author: ksrini Date: 2008-09-04 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/150a441a305d 6733959: Insufficient checks for "Main-Class" manifest entry in JAR files Summary: Fixes a buffer overrun problem with a very long Main-Class attribute. Reviewed-by: darcy ! src/share/bin/emessages.h ! src/share/bin/java.c ! test/tools/launcher/MultipleJRE.sh + test/tools/launcher/ZipMeUp.java Changeset: ec336f0e23f4 Author: okutsu Date: 2008-10-02 16:49 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ec336f0e23f4 6734167: Calendar.readObject allows elevation of privileges Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: 135c5fe2ee42 Author: bae Date: 2008-10-02 20:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/135c5fe2ee42 6726779: ConvolveOp on USHORT raster can cause the JVM crash. Reviewed-by: igor, prr ! src/share/native/sun/awt/medialib/awt_ImagingLib.c + test/java/awt/image/ConvolveOp/EdgeNoOpCrash.java Changeset: 9d1033f65e4b Author: alanb Date: 2008-10-09 21:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9d1033f65e4b 6721753: File.createTempFile produces guessable file names Reviewed-by: sherman ! src/share/classes/java/io/File.java Changeset: 3c567ab34788 Author: ksrini Date: 2008-10-17 09:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3c567ab34788 6755943: Java JAR Pack200 Decompression should enforce stricter header checks Summary: Fixes a core dump when fed with a faulty pack file and related malicious take over Reviewed-by: jrose ! make/common/shared/Defs-windows.gmk ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h + test/tools/pack200/MemoryAllocatorTest.java Changeset: 0291de857e51 Author: bae Date: 2008-12-03 13:34 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0291de857e51 6766136: corrupted gif image may cause crash in java splashscreen library. Reviewed-by: prr, art ! src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.h ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c Changeset: dfb09d805b2d Author: prr Date: 2008-12-24 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dfb09d805b2d 6652463: MediaSize constructors allow to redefine the mapping of standard MediaSizeName values Reviewed-by: igor, jgodinez ! src/share/classes/javax/print/attribute/standard/MediaSize.java + test/javax/print/attribute/MediaMappingsTest.java Changeset: a8ec0998704e Author: weijun Date: 2008-12-30 10:42 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a8ec0998704e 6717680: LdapCtx does not close the connection if initialization fails Reviewed-by: vinnie, xuelei ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java Changeset: 6a4e03cc03bb Author: prr Date: 2009-01-05 11:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6a4e03cc03bb 6632886: Font.createFont can be persuaded to leak temporary files 6522586: Enforce limits on Font creation 6652929: Font.createFont(int,File) trusts File.getPath Reviewed-by: igor ! src/share/classes/java/awt/Font.java + src/share/classes/sun/font/CreatedFontTracker.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FontManager.java + test/java/awt/FontClass/CreateFont/A.ttf + test/java/awt/FontClass/CreateFont/BigFont.java + test/java/awt/FontClass/CreateFont/DeleteFont.java + test/java/awt/FontClass/CreateFont/DeleteFont.sh + test/java/awt/FontClass/CreateFont/bigfont.html + test/java/awt/FontClass/CreateFont/fileaccess/FontFile.java Changeset: 392c4225d636 Author: ksrini Date: 2009-02-18 14:14 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/392c4225d636 6792554: Java JAR Pack200 header checks are insufficent Summary: Added several checks to ensure that the values read from the headers are consistent Reviewed-by: jrose ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/coding.cpp ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp - test/tools/pack200/MemoryAllocatorTest.java Changeset: 7f4cf1eb7586 Author: bae Date: 2009-02-20 13:48 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7f4cf1eb7586 6804996: JWS PNG Decoding Integer Overflow [V-flrhat2ln8] Reviewed-by: prr ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/share/native/sun/awt/splashscreen/splashscreen_impl.h ! src/share/native/sun/awt/splashscreen/splashscreen_png.c Changeset: dedf9366f289 Author: prr Date: 2009-03-03 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/dedf9366f289 2163516: Font.createFont can be persuaded to leak temporary files Reviewed-by: igor ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! test/java/awt/FontClass/CreateFont/DeleteFont.java Changeset: 7f6c1ce75629 Author: bae Date: 2009-03-05 19:36 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7f6c1ce75629 6804998: JRE GIF Decoding Heap Corruption [V-y6g5jlm8e1] Reviewed-by: prr ! src/share/classes/sun/awt/image/GifImageDecoder.java ! src/share/native/sun/awt/image/gif/gifdecoder.c Changeset: 51f13571014c Author: bae Date: 2009-03-06 12:40 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/51f13571014c 6804997: JWS GIF Decoding Heap Corruption [V-r687oxuocp] Reviewed-by: prr ! src/share/native/sun/awt/giflib/dgif_lib.c Changeset: 2e34ef54a93a Author: michaelm Date: 2009-03-10 03:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/2e34ef54a93a 6630639: lightweight HttpServer leaks file descriptors on no-data connections Summary: not cleaning up no-data connections properly Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: 21e38c573956 Author: dfuchs Date: 2009-03-09 21:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/21e38c573956 6656633: getNotificationInfo methods static mutable Reviewed-by: emcmanus, jfdenise ! src/share/classes/javax/management/monitor/CounterMonitor.java ! src/share/classes/javax/management/monitor/GaugeMonitor.java ! src/share/classes/javax/management/monitor/StringMonitor.java Changeset: ea88236be621 Author: dfuchs Date: 2009-03-10 12:28 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ea88236be621 Merge Changeset: 8cdfcdea53cb Author: dfuchs Date: 2009-03-09 22:17 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8cdfcdea53cb 6691246: Thread context class loader can be set using JMX remote ClientNotifForwarded Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java Changeset: 09b17f679cbd Author: dfuchs Date: 2009-03-10 12:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/09b17f679cbd Merge Changeset: 13dfb2c46091 Author: dfuchs Date: 2009-03-09 22:34 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/13dfb2c46091 6610888: Potential use of cleared of incorrect acc in JMX Monitor Reviewed-by: emcmanus ! src/share/classes/javax/management/monitor/Monitor.java Changeset: de520a184ddb Author: dfuchs Date: 2009-03-10 12:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/de520a184ddb Merge Changeset: 8062f8c51a88 Author: dfuchs Date: 2009-03-09 22:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8062f8c51a88 6610896: JMX Monitor handles thread groups incorrectly Reviewed-by: emcmanus ! src/share/classes/javax/management/monitor/Monitor.java Changeset: e1d79edaf7a0 Author: dfuchs Date: 2009-03-10 12:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e1d79edaf7a0 Merge ! src/share/classes/javax/management/monitor/Monitor.java Changeset: 3265fb461090 Author: dfuchs Date: 2009-03-09 23:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/3265fb461090 6721651: Security problem with out-of-the-box management Reviewed-by: emcmanus, lmalvent ! src/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java ! src/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/share/lib/management/jmxremote.access Changeset: 6ed878e5a5d4 Author: dfuchs Date: 2009-03-10 14:29 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6ed878e5a5d4 Merge Changeset: 255dcd4f19b6 Author: vinnie Date: 2009-03-10 18:43 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/255dcd4f19b6 6737315: LDAP serialized data vulnerability Reviewed-by: alanb ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java Changeset: e51956c74e5c Author: asaha Date: 2009-04-16 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e51956c74e5c Merge ! make/common/shared/Defs-windows.gmk ! src/share/bin/emessages.h ! src/share/bin/java.c ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/io/File.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/javax/management/monitor/CounterMonitor.java ! src/share/classes/javax/management/monitor/GaugeMonitor.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/coding.cpp ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 16c5e63f32d2 Author: asaha Date: 2009-04-16 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/16c5e63f32d2 Merge - src/share/native/java/util/zip/ZipEntry.c Changeset: a498d2817bef Author: asaha Date: 2009-04-17 09:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a498d2817bef Merge Changeset: f1c76fb74e57 Author: tbell Date: 2009-04-18 14:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f1c76fb74e57 Merge ! src/share/classes/sun/font/FontManager.java - src/share/native/java/util/zip/ZipEntry.c Changeset: ccd08d4b19cf Author: alanb Date: 2009-04-20 09:30 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ccd08d4b19cf 6830721: (fc) test/java/nio/channels/AsynchronousFileChannel/Basic.java intermittent failure Reviewed-by: sherman ! test/java/nio/channels/AsynchronousFileChannel/Basic.java Changeset: e281812be4ce Author: alanb Date: 2009-04-20 13:27 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e281812be4ce 6831461: (sample) Copy -r fails with IllegalArgumentexception: 'maxDepth' is negative Reviewed-by: chegar ! src/share/sample/nio/file/Copy.java Changeset: 697bf0cf039b Author: martin Date: 2009-04-20 21:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/697bf0cf039b 6830220: Logging issues due to regression from bug fix 6797480 Reviewed-by: swamyv Contributed-by: jeremymanson at google.com ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerSubclass.java Changeset: 079985c9965b Author: martin Date: 2009-04-20 21:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/079985c9965b 6716076: test UTIL_REGRESSION/test/java/util/logging/LoggingDeadlock2.java failed with exit code 1 Reviewed-by: swamyv, mchung ! test/java/util/logging/LoggingDeadlock2.java Changeset: 0fd45dba3cc8 Author: martin Date: 2009-04-20 21:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0fd45dba3cc8 6278014: java.util.logging.LogRecord.getThreadID() should provide real thread id Summary: Make j.u.l. thread id a copy of Thread's id, for small values of thread id. Reviewed-by: alanb ! src/share/classes/java/util/logging/LogRecord.java ! test/java/util/logging/LoggerSubclass.java Changeset: c35a027468f2 Author: tbell Date: 2009-04-21 08:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c35a027468f2 6831313: update jaxws in OpenJDK7 to 2.1 plus bug fixes from OpenJDK 6 6672868: Package javax.xml.ws.wsaddressing not included in make/docs/CORE_PKGS.gmk Reviewed-by: darcy ! make/docs/CORE_PKGS.gmk Changeset: cc5db1a62f70 Author: tbell Date: 2009-04-21 09:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/cc5db1a62f70 Merge - make/common/shared/Compiler.gmk - make/jprt.config - src/share/classes/sun/text/normalizer/UProperty.java - src/share/native/java/util/zip/ZipEntry.c - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties - src/windows/native/sun/windows/awt_KeyboardFocusManager.h Changeset: ea611a547fbf Author: tbell Date: 2009-04-21 21:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/ea611a547fbf Merge - src/share/native/java/util/zip/ZipEntry.c Changeset: 7859c68fed2b Author: tbell Date: 2009-04-23 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7859c68fed2b Merge Changeset: 31a9fa5a8e6b Author: ohair Date: 2009-04-27 20:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/31a9fa5a8e6b 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties Changeset: 45dfc3aeee8f Author: ohair Date: 2009-04-28 14:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/45dfc3aeee8f 6835241: Annotate some tests with @ignore that have shown to be unpredictable Reviewed-by: tbell ! test/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/management/ThreadMXBean/ThreadStateTest.java ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/util/logging/LoggingDeadlock2.java Changeset: 8dd1c3eb1288 Author: denis Date: 2009-04-13 21:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8dd1c3eb1288 6590857: Drag & Drop arbitrary file copy Reviewed-by: uta ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: 98ddbb3840a4 Author: anthony Date: 2009-04-14 14:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/98ddbb3840a4 6825342: Security warning may change Z-order of top-level Summary: Added the SWP_NOOWNERZORDER flag when calling ::SetWindowPos() Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 6f4446ca5499 Author: yan Date: 2009-04-16 23:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6f4446ca5499 Merge - make/common/shared/Compiler.gmk - make/jprt.config - src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java - src/share/classes/sun/text/normalizer/UProperty.java - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/awt/windows/fontconfig.98.properties - src/windows/classes/sun/awt/windows/fontconfig.Me.properties - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: c6503f2a93d1 Author: anthony Date: 2009-04-17 16:16 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/c6503f2a93d1 6826104: Getting a NullPointer exception when clicked on Application & Toolkit Modal dialog Summary: The addition of window peers to the windows collection has been restored in XWindowPeer. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 9124b0123df3 Author: anthony Date: 2009-04-17 16:30 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9124b0123df3 6821948: Consider removing the constraints for bounds of untrusted top-level windows Summary: The constrainBounds() methods are removed. Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/WDialogPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 5555093749ab Author: anthony Date: 2009-04-17 16:42 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5555093749ab 6829858: JInternalFrame is not redrawing heavyweight children properly Summary: The Container.recursiveApplyCurrentShape() is now recursively called for all hw containers, even those having non-null layout Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java + test/java/awt/Mixing/MixingInHwPanel.java Changeset: bd06d33634ee Author: dcherepanov Date: 2009-04-20 14:41 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/bd06d33634ee 6633354: AppletPanel loads Swing classes Reviewed-by: art, anthony ! src/share/classes/sun/applet/AppletPanel.java Changeset: 0d03c3cc2f03 Author: dcherepanov Date: 2009-04-20 17:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/0d03c3cc2f03 6770457: Using ToolTips causes inactive app window to exhibit active window behavior Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h Changeset: 68ce3fa2b4c5 Author: dcherepanov Date: 2009-04-20 19:18 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/68ce3fa2b4c5 6825362: Avoid calling peer.setZOrder on Window instances Reviewed-by: anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Window.java ! src/windows/classes/sun/awt/windows/WPanelPeer.java Changeset: 9cb0aecf54bd Author: anthony Date: 2009-04-21 11:35 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/9cb0aecf54bd 6802853: API: shaped & translucent windows Summary: A public API for the feature forward-ported from 6u10. Reviewed-by: yan ! src/share/classes/java/awt/GraphicsConfiguration.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/Window.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/windows/classes/sun/awt/Win32GraphicsConfig.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java + test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java + test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java + test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form + test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: 48df681dc50a Author: yan Date: 2009-04-28 13:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/48df681dc50a Merge - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: 7601454859c2 Author: art Date: 2009-04-17 12:46 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7601454859c2 6829923: Test javax/swing/system/6799345/TestShutdown.java fails on X11 platforms Summary: XAWT toolkit thread is correctly interrupted when AppContext is disposed Reviewed-by: anthony, peterz ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 8e01a3dee336 Author: amenkov Date: 2009-04-17 15:02 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8e01a3dee336 5050147: RFE: Add More Useful Constructors to MidiMessage Subclasses Reviewed-by: alexp ! src/share/classes/javax/sound/midi/MetaMessage.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/SysexMessage.java Changeset: f94a3aaae91d Author: amenkov Date: 2009-04-17 15:10 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/f94a3aaae91d 4672194: FloatControl should provide consistent policy for the floats Reviewed-by: alexp ! src/share/classes/javax/sound/sampled/FloatControl.java Changeset: e7b19babfd80 Author: amenkov Date: 2009-04-17 15:11 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e7b19babfd80 4895403: SPEC: documentation of javax.sound.sampled.spi.MixerProvider should be detailed Reviewed-by: malenkov ! src/share/classes/javax/sound/sampled/spi/MixerProvider.java Changeset: a301fb619494 Author: amenkov Date: 2009-04-17 15:15 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/a301fb619494 6806019: 38 JCK api/javax_sound/midi/ tests fails starting from jdk7 b46 Reviewed-by: kalli ! src/share/classes/com/sun/media/sound/SoftSynthesizer.java Changeset: 923a730165bf Author: kalli Date: 2009-04-17 16:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/923a730165bf 6821030: Merge OpenJDK Gervill with upstream sources, Q1CY2009 Reviewed-by: darcy, amenkov ! src/share/classes/com/sun/media/sound/SoftAudioPusher.java ! src/share/classes/com/sun/media/sound/SoftChannel.java ! src/share/classes/com/sun/media/sound/SoftChorus.java ! src/share/classes/com/sun/media/sound/SoftFilter.java ! src/share/classes/com/sun/media/sound/SoftJitterCorrector.java ! src/share/classes/com/sun/media/sound/SoftMainMixer.java ! src/share/classes/com/sun/media/sound/SoftVoice.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java + test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java Changeset: e61cd67602bd Author: kalli Date: 2009-04-17 16:20 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/e61cd67602bd 6823445: Gervill SoftChannel/ResetAllControllers jtreg test fails after portamento fix from last merge. Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/SoftChannel.java Changeset: 5ac8b97ffabd Author: kalli Date: 2009-04-17 16:28 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/5ac8b97ffabd 6823446: Gervill SoftLowFrequencyOscillator fails when freq is set to 0 cent or 8.1758 Hz. Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java + test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java Changeset: 7f45fcc04f8e Author: peterz Date: 2009-04-25 21:17 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/7f45fcc04f8e 6591875: Nimbus Swing Look and Feel Reviewed-by: jasper, ohair ! README ! make/common/Sanity.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.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/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 + src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java + src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java + src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Color.java ! src/share/classes/javax/swing/DefaultCellEditor.java ! src/share/classes/javax/swing/DefaultListCellRenderer.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/MultiUIDefaults.java + src/share/classes/javax/swing/Painter.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.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/DropShadowEffect.java + src/share/classes/javax/swing/plaf/nimbus/Effect.java + src/share/classes/javax/swing/plaf/nimbus/EffectUtils.java + src/share/classes/javax/swing/plaf/nimbus/ImageCache.java + src/share/classes/javax/swing/plaf/nimbus/ImageScalingHelper.java + src/share/classes/javax/swing/plaf/nimbus/InnerGlowEffect.java + src/share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java + src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java + src/share/classes/javax/swing/plaf/nimbus/NimbusIcon.java + src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java + src/share/classes/javax/swing/plaf/nimbus/OuterGlowEffect.java + src/share/classes/javax/swing/plaf/nimbus/PainterImpl.template + src/share/classes/javax/swing/plaf/nimbus/ShadowEffect.java + src/share/classes/javax/swing/plaf/nimbus/State.java + src/share/classes/javax/swing/plaf/nimbus/StateImpl.template + src/share/classes/javax/swing/plaf/nimbus/SynthPainterImpl.java + src/share/classes/javax/swing/plaf/nimbus/TableScrollPaneCorner.java + src/share/classes/javax/swing/plaf/nimbus/ToolBarSeparatorPainter.java + src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html + src/share/classes/javax/swing/plaf/nimbus/package.html + src/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/share/classes/javax/swing/plaf/synth/SynthArrowButton.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/sun/swing/DefaultLookup.java ! src/share/classes/sun/swing/FilePane.java + src/share/classes/sun/swing/plaf/GTKKeybindings.java + src/share/classes/sun/swing/plaf/WindowsKeybindings.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java Changeset: 8df0db057762 Author: peterz Date: 2009-04-28 21:41 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/8df0db057762 6835113: Nimbus Makefile issue Reviewed-by: prr ! make/tools/swing-nimbus/Makefile Changeset: 4b922e8fef3b Author: yan Date: 2009-04-28 13:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/4b922e8fef3b Merge ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: d5a1223e9618 Author: yan Date: 2009-04-29 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/d5a1223e9618 Merge - test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form - test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java Changeset: 6c7c0bccab55 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/jdk/rev/6c7c0bccab55 Added tag jdk7-b57 for changeset d5a1223e9618 ! .hgtags From john.coomes at sun.com Thu Apr 30 23:27:35 2009 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 01 May 2009 06:27:35 +0000 Subject: hg: jdk7/hotspot-gc/langtools: 2 new changesets Message-ID: <20090501062740.9630AED2E@hg.openjdk.java.net> Changeset: 4030cc469205 Author: ohair Date: 2009-04-27 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/4030cc469205 6831225: Upgrade JPRT jobs to use newer Linux 2.6 (e.g. Fedora 9) Reviewed-by: tbell ! make/jprt.properties Changeset: 8a2424db1a14 Author: xdono Date: 2009-04-30 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/langtools/rev/8a2424db1a14 Added tag jdk7-b57 for changeset 4030cc469205 ! .hgtags