From chris.hegarty at oracle.com Wed Dec 1 11:54:58 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 01 Dec 2010 11:54:58 +0000 Subject: 6709457: (fc) lock/tryLock() throws IOException "Access is denied" when file opened for append [win] In-Reply-To: <4CF38D9B.4010209@oracle.com> References: <4CF38D9B.4010209@oracle.com> Message-ID: <4CF63792.4050900@oracle.com> Alan, I think the changes are fine. -Chris. On 29/11/2010 11:25, Alan Bateman wrote: > > This is an awkward regression that Martin and I previously discussed on > this list [1]. > > To re-cap: When the redirection API for sub-processes was added early in > jdk7, FileOutputStream was changed on Windows so that opening a file in > append mode results in the write-at-end to be atomic. It achieves this > by opening the file with FILE_APPEND_DATA and not FILE_WRITE_DATA > access. Unfortunately this change came with side effects, the main one > being that it breaks the file locking facility for files opened for > append. We also observed that files opened for append cannot be > truncated, potentially an issue for code that wants to truncate a log > file for example. > > The changes here are along the lines that we discussed. First, the > opening of files for append is changed back to using GENERIC_WRITE mode. > Secondly, writing is changed so that it does a write-at-end. This is > probably the way it should have been done originally. For the > redirection API, the Windows implementation is changed so that it opens > the output file in FILE_APPEND_DATA mode. This gives us the semantics > that we want as we have no control as to how the sub-process will write > to its output or error streams. One thing to point out is that I have > deliberately kept the code as simple as possible. That is, I have not > duplicated the code for long file handling and all the other odd cases > that Windows entails. The rational is that we could could easily just > eliminate this and have it use the new file system API to open the file > (as supporting platform specific options there is easy). However, there > are modularity concerns with creating that dependency and it might be > better to see how that plays out first. We can create a low priority bug > as a reminder of this odd cases. That's mostly it except for some > additional tests for these scenarios. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/6709457/webrev/ > > Thanks, > > -Alan. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-June/000468.html > From joe.darcy at oracle.com Wed Dec 1 17:24:30 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 01 Dec 2010 09:24:30 -0800 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" Message-ID: <4CF684CE.5080807@oracle.com> Hello. Please review my simple fix for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" http://cr.openjdk.java.net/~darcy/7002594.0/ Besides addressing the reported issues with max/min, I also review the other uses of those methods in java.lang.* and added a comment or two. While looking over sun/misc/FpUtils.java, I took the opportunity to update the javadoc style. Thanks, -Joe From mike.duigou at oracle.com Wed Dec 1 18:47:04 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 1 Dec 2010 10:47:04 -0800 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" In-Reply-To: <4CF684CE.5080807@oracle.com> References: <4CF684CE.5080807@oracle.com> Message-ID: <8DC0B9B7-1534-42FA-9143-1B885D3D6519@oracle.com> All looks good to me. Understanding why the maxs check Double.doubleToRawLongBits(a) and the mins check Double.doubleToRawLongBits(b) required reading the javadoc. :-) Mike On Dec 1 2010, at 09:24 , Joe Darcy wrote: > Hello. > > Please review my simple fix for > > 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" > http://cr.openjdk.java.net/~darcy/7002594.0/ > > Besides addressing the reported issues with max/min, I also review the other uses of those methods in java.lang.* and added a comment or two. While looking over sun/misc/FpUtils.java, I took the opportunity to update the javadoc style. > > Thanks, > > -Joe From bhavesh.patel at sun.com Wed Dec 1 19:07:06 2010 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Wed, 01 Dec 2010 19:07:06 +0000 Subject: hg: jdk7/tl/langtools: 6851834: Javadoc doclet needs a structured approach to generate the output HTML. Message-ID: <20101201190708.302D347FE3@hg.openjdk.java.net> Changeset: 90af8d87741f Author: bpatel Date: 2010-12-01 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/90af8d87741f 6851834: Javadoc doclet needs a structured approach to generate the output HTML. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! 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/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.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/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.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/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.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/PackageFrameWriter.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/PackageTreeWriter.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/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.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/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java + src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java ! test/com/sun/javadoc/AccessSummary/AccessSummary.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/ValidHtml/ValidHtml.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java ! test/com/sun/javadoc/WindowTitles/WindowTitles.java ! test/com/sun/javadoc/constantValues/TestConstantValuesDriver.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testDocRootInlineTag/TestDocRootInlineTag.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java + test/com/sun/javadoc/testHtmlDocument/testLink.html + test/com/sun/javadoc/testHtmlDocument/testMarkup.html ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInlineLinkLabel/TestInlineLinkLabel.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkToSerialForm/TestLinkToSerialForm.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java ! test/com/sun/javadoc/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java ! test/com/sun/javadoc/testTitleInHref/TestTitleInHref.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java From Lance.Andersen at oracle.com Wed Dec 1 19:12:22 2010 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 1 Dec 2010 14:12:22 -0500 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" In-Reply-To: <4CF684CE.5080807@oracle.com> References: <4CF684CE.5080807@oracle.com> Message-ID: <36AC7083-181C-4190-BE4A-4B5DD32CC6F3@oracle.com> Hi Joe, Looks fine to me. -lance On Dec 1, 2010, at 12:24 PM, Joe Darcy wrote: > Hello. > > Please review my simple fix for > > 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" > http://cr.openjdk.java.net/~darcy/7002594.0/ > > Besides addressing the reported issues with max/min, I also review the other uses of those methods in java.lang.* and added a comment or two. While looking over sun/misc/FpUtils.java, I took the opportunity to update the javadoc style. > > Thanks, > > -Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Dec 1 19:23:51 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 01 Dec 2010 20:23:51 +0100 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" In-Reply-To: <4CF684CE.5080807@oracle.com> References: <4CF684CE.5080807@oracle.com> Message-ID: <4CF6A0C7.7060405@univ-mlv.fr> On 12/01/2010 06:24 PM, Joe Darcy wrote: > Hello. > > Please review my simple fix for > > 7002594 "Math.max and Math.min should use floatToRawIntBits() to > check for -0.0" > http://cr.openjdk.java.net/~darcy/7002594.0/ > > Besides addressing the reported issues with max/min, I also review the > other uses of those methods in java.lang.* and added a comment or > two. While looking over sun/misc/FpUtils.java, I took the opportunity > to update the javadoc style. > > Thanks, > > -Joe Looks fine. I just wonder why twoToTheDoubleScaleUp and twoToTheDoubleScaleDown in FpUtils aren't real constants (static final). R?mi From alan.bateman at oracle.com Wed Dec 1 19:41:10 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 01 Dec 2010 19:41:10 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101201194129.1900747FE5@hg.openjdk.java.net> Changeset: 374cc848d797 Author: alanb Date: 2010-12-01 13:49 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/374cc848d797 6709457: (fc) lock/tryLock() throws IOException "Access is denied" when file opened for append [win] Reviewed-by: chegar ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/native/java/io/RandomAccessFile.c ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h ! src/solaris/classes/java/lang/ProcessImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/native/java/io/FileOutputStream_md.c ! src/solaris/native/java/io/io_util_md.h ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/fs/WindowsChannelFactory.java ! src/windows/native/java/io/FileOutputStream_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/sun/nio/ch/FileDispatcherImpl.c + test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Lock.java ! test/java/nio/channels/FileChannel/Truncate.java Changeset: a5ec2488bdc0 Author: alanb Date: 2010-12-01 19:40 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5ec2488bdc0 Merge From mandy.chung at oracle.com Wed Dec 1 19:46:20 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 01 Dec 2010 11:46:20 -0800 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" In-Reply-To: <4CE59DFB.9050909@oracle.com> References: <4CE59DFB.9050909@oracle.com> Message-ID: <4CF6A60C.2020609@oracle.com> Mike, Alan, I have updated the fix to use GetFileSizeEx() and SetFilePointerEx(). Also add a regression test that creates a large sparse file. Webrev at: http://cr.openjdk.java.net/~mchung/6402006/webrev.01/ Thanks Mandy On 11/18/10 13:43, Mandy Chung wrote: > 6402006 FileInputStream.available() returns negative values when > reading a large file > > Webrev at: > http://cr.openjdk.java.net/~mchung/6402006/webrev.00/ > > This fixes a bug in the windows implementation of io_util.c that > ignores the high-order doubleword of the file size in computing the > end of the file. Thus the available() method incorrectly returns only > the low-order 32-bit for large files. > > Thanks > Mandy From Alan.Bateman at oracle.com Wed Dec 1 19:58:29 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Dec 2010 19:58:29 +0000 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" In-Reply-To: <4CF684CE.5080807@oracle.com> References: <4CF684CE.5080807@oracle.com> Message-ID: <4CF6A8E5.1020001@oracle.com> Joe Darcy wrote: > Hello. > > Please review my simple fix for > > 7002594 "Math.max and Math.min should use floatToRawIntBits() to > check for -0.0" > http://cr.openjdk.java.net/~darcy/7002594.0/ > > Besides addressing the reported issues with max/min, I also review the > other uses of those methods in java.lang.* and added a comment or > two. While looking over sun/misc/FpUtils.java, I took the opportunity > to update the javadoc style. > > Thanks, > > -Joe Looks good to me, and the clean-ups looks fine too. -Alan. From joe.darcy at oracle.com Wed Dec 1 21:02:52 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 01 Dec 2010 21:02:52 +0000 Subject: hg: jdk7/tl/jdk: 7002594: Math.max and Math.min should use floatToRawIntBits() to check for -0.0 Message-ID: <20101201210302.6E72347FE9@hg.openjdk.java.net> Changeset: 8aabca72877c Author: darcy Date: 2010-12-01 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8aabca72877c 7002594: Math.max and Math.min should use floatToRawIntBits() to check for -0.0 Reviewed-by: mduigou, lancea, alanb ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/sun/misc/FpUtils.java From Alan.Bateman at oracle.com Wed Dec 1 21:39:08 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Dec 2010 21:39:08 +0000 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" In-Reply-To: <4CF6A60C.2020609@oracle.com> References: <4CE59DFB.9050909@oracle.com> <4CF6A60C.2020609@oracle.com> Message-ID: <4CF6C07C.3010508@oracle.com> Mandy Chung wrote: > Mike, Alan, > > I have updated the fix to use GetFileSizeEx() and SetFilePointerEx(). > Also add a regression test that creates a large sparse file. > > Webrev at: > http://cr.openjdk.java.net/~mchung/6402006/webrev.01/ This looks much better, and the implementation changes looks okay to me . Thanks for including a test case. A few minor nits: - at L46, the name "pos" is a bit mis-leading as it's a big skip value rather than a position. - it might be cleaner if skipBytes returned the number of bytes skipped rather then incrementing a static. That way you could initialize remaining to FILESIZE and then reduce it by the number of bytes skipped. - it's a bit strange for createLargeFile to arrange for the file to be deleted on exit, that seems to be something for the caller to arrange. - At L85, bb.flip would be more correct. Otherwise looks good to me. -Alan. From mandy.chung at oracle.com Wed Dec 1 21:46:06 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 01 Dec 2010 13:46:06 -0800 Subject: Code review request "6402006: FileInputStream.available() returns negative values when reading a large file" In-Reply-To: <4CF6C07C.3010508@oracle.com> References: <4CE59DFB.9050909@oracle.com> <4CF6A60C.2020609@oracle.com> <4CF6C07C.3010508@oracle.com> Message-ID: <4CF6C21E.3090705@oracle.com> On 12/01/10 13:39, Alan Bateman wrote: > Mandy Chung wrote: >> Mike, Alan, >> >> I have updated the fix to use GetFileSizeEx() and >> SetFilePointerEx(). Also add a regression test that creates a large >> sparse file. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6402006/webrev.01/ > This looks much better, and the implementation changes looks okay to me . > > Thanks for including a test case. A few minor nits: > > - at L46, the name "pos" is a bit mis-leading as it's a big skip value > rather than a position. Agree and will rename it. > - it might be cleaner if skipBytes returned the number of bytes > skipped rather then incrementing a static. That way you could > initialize remaining to FILESIZE and then reduce it by the number of > bytes skipped. The skippedBytes variable is solely for troubleshooting use . I could move the System.out.println after each skipBytes call. > - it's a bit strange for createLargeFile to arrange for the file to be > deleted on exit, that seems to be something for the caller to arrange. > - At L85, bb.flip would be more correct. > Ok. Will update it. > Otherwise looks good to me. > Thanks for the review. Mandy > -Alan. From chris.hegarty at oracle.com Wed Dec 1 21:48:15 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 01 Dec 2010 21:48:15 +0000 Subject: hg: jdk7/tl/jdk: 7003745: Code style cleanups (sync from Dougs CVS) Message-ID: <20101201214825.54C8A47FEC@hg.openjdk.java.net> Changeset: 9e494de19690 Author: dl Date: 2010-12-01 21:46 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9e494de19690 7003745: Code style cleanups (sync from Dougs CVS) Reviewed-by: chegar, dholmes ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/Stack.java ! src/share/classes/java/util/TimSort.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/BlockingQueue/LoopHelpers.java ! test/java/util/concurrent/ConcurrentHashMap/LoopHelpers.java ! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java ! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java ! test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java ! test/java/util/concurrent/CopyOnWriteArrayList/EqualsRace.java ! test/java/util/concurrent/CopyOnWriteArraySet/RacingCows.java ! test/java/util/concurrent/CyclicBarrier/Basic.java ! test/java/util/concurrent/Exchanger/ExchangeLoops.java ! test/java/util/concurrent/Exchanger/LoopHelpers.java ! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java ! test/java/util/concurrent/ExecutorCompletionService/LoopHelpers.java ! test/java/util/concurrent/Executors/Throws.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/FutureTask/CancelledFutureLoops.java ! test/java/util/concurrent/FutureTask/Customized.java ! test/java/util/concurrent/FutureTask/LoopHelpers.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java ! test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/ThreadPoolExecutor/ScheduledTickleService.java ! test/java/util/concurrent/ThreadPoolExecutor/ShutdownNowExecuteRace.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/atomic/VMSupportsCS8.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java ! test/java/util/concurrent/locks/ReentrantLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/Bug6571733.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/LoopHelpers.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java From joe.darcy at oracle.com Wed Dec 1 22:33:49 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 01 Dec 2010 14:33:49 -0800 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" In-Reply-To: <4CF6A0C7.7060405@univ-mlv.fr> References: <4CF684CE.5080807@oracle.com> <4CF6A0C7.7060405@univ-mlv.fr> Message-ID: <4CF6CD4D.2070607@oracle.com> R?mi Forax wrote: > On 12/01/2010 06:24 PM, Joe Darcy wrote: >> Hello. >> >> Please review my simple fix for >> >> 7002594 "Math.max and Math.min should use floatToRawIntBits() to >> check for -0.0" >> http://cr.openjdk.java.net/~darcy/7002594.0/ >> >> Besides addressing the reported issues with max/min, I also review >> the other uses of those methods in java.lang.* and added a comment or >> two. While looking over sun/misc/FpUtils.java, I took the >> opportunity to update the javadoc style. >> >> Thanks, >> >> -Joe > > Looks fine. > > I just wonder why twoToTheDoubleScaleUp and twoToTheDoubleScaleDown in > FpUtils > aren't real constants (static final). Just an oversight; they are logically constants -- the next time I edit this class, I'll fix that. Thanks, -Joe From mandy.chung at oracle.com Wed Dec 1 23:59:08 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 01 Dec 2010 23:59:08 +0000 Subject: hg: jdk7/tl/jdk: 6402006: FileInputStream.available() returns negative values when reading a large file Message-ID: <20101201235917.B85F647FF1@hg.openjdk.java.net> Changeset: 8b2025d6f257 Author: mchung Date: 2010-12-01 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b2025d6f257 6402006: FileInputStream.available() returns negative values when reading a large file Reviewed-by: alanb ! src/windows/native/java/io/io_util_md.c + test/java/io/FileInputStream/LargeFileAvailable.java From Ulf.Zibis at gmx.de Thu Dec 2 17:38:01 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 02 Dec 2010 18:38:01 +0100 Subject: Code review request for 7002594 "Math.max and Math.min should use floatToRawIntBits() to check for -0.0" In-Reply-To: <4CF6CD4D.2070607@oracle.com> References: <4CF684CE.5080807@oracle.com> <4CF6A0C7.7060405@univ-mlv.fr> <4CF6CD4D.2070607@oracle.com> Message-ID: <4CF7D979.8050806@gmx.de> Am 01.12.2010 23:33, schrieb Joe Darcy: > R?mi Forax wrote: >> >> I just wonder why twoToTheDoubleScaleUp and twoToTheDoubleScaleDown in FpUtils >> aren't real constants (static final). > > Just an oversight; they are logically constants -- the next time I edit this class, I'll fix that. IMHO those constants are superfluous, as they are only used once. Additionally, scale_factor only needs to range-adjusted in [-MAX_SCALE, MAX_SCALE] So we can code much more simple: public static double scalb(double d, int scale_factor) { // ... final int MAX_SCALE = DoubleConsts.MAX_EXPONENT + -DoubleConsts.MIN_EXPONENT + DoubleConsts.SIGNIFICAND_WIDTH + 1; // Make sure scaling factor is in a reasonable range scale_factor = Math.min(Math.max(scale_factor, -MAX_SCALE), MAX_SCALE); int scale_delta= 512; double exp_delta = powerOfTwoD(scale_delta); if(scale_factor < 0) exp_delta = powerOfTwoD(scale_delta= -scale_delta); // Calculate (scale_factor % +/-512), 512 = 2^9, using // technique from "Hacker's Delight" section 10-2. final int t = (scale_factor >> 9-1) >>> 32 - 9; final int exp_adjust = ((scale_factor + t) & (512 -1)) - t; for(d*=powerOfTwoD(exp_adjust), scale_factor-=exp_adjust; scale_factor!=0; scale_factor-=scale_delta) d *= exp_delta; return d; } And even more simpler, if we trust the optimizer: public static double scalb(double d, int scale_factor) { // ... final int MAX_SCALE = DoubleConsts.MAX_EXPONENT + -DoubleConsts.MIN_EXPONENT + DoubleConsts.SIGNIFICAND_WIDTH + 1; // Make sure scaling factor is in a reasonable range scale_factor = Math.min(Math.max(scale_factor, -MAX_SCALE), MAX_SCALE); final int scale_delta = scale_factor < 0 ? -512 : 512; final double exp_delta = powerOfTwoD(scale_delta); // Calculate (scale_factor % +/-512), 512 = 2^9, using // technique from "Hacker's Delight" section 10-2. final int t = (scale_factor >> 9-1) >>> 32 - 9; final int exp_adjust = ((scale_factor + t) & (512 -1)) - t; for(d*=powerOfTwoD(exp_adjust), scale_factor-=exp_adjust; scale_factor!=0; scale_factor-=scale_delta) d *= exp_delta; return d; } - Ulf From abhi.saha at oracle.com Thu Dec 2 17:55:40 2010 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Thu, 02 Dec 2010 17:55:40 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101202175543.90EC54701F@hg.openjdk.java.net> Changeset: 6fe70c295e96 Author: skoppar Date: 2010-11-21 21:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6fe70c295e96 6980681: CORBA deadlock in Java SE beleived to be related to CR 6238477 Summary: Also reviewed by ken.cavanaugh at oracle.com Reviewed-by: poonam ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java Changeset: d2049cfdf02b Author: asaha Date: 2010-12-01 16:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/d2049cfdf02b Merge ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java From jonathan.gibbons at oracle.com Fri Dec 3 00:38:28 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 03 Dec 2010 00:38:28 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101203003832.391D247030@hg.openjdk.java.net> Changeset: 7e3e9f6d013f Author: jjg Date: 2010-12-02 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7e3e9f6d013f 7004029: intermittent failures compiling pack200 Summary: remove "bogus" entries from star-import scopes Reviewed-by: mcimadamore Contributed-by: per.bothner at oracle.com ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/scope/HashCollisionTest.java + test/tools/javac/scope/StarImportTest.java Changeset: 28566c763dad Author: jjg Date: 2010-12-02 16:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/28566c763dad Merge - src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java From xuelei.fan at oracle.com Fri Dec 3 07:45:25 2010 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 03 Dec 2010 07:45:25 +0000 Subject: hg: jdk7/tl/jdk: 6979376: to have ldap filters tolerate underscore character in object identifier Message-ID: <20101203074540.B4BF147063@hg.openjdk.java.net> Changeset: 0e0bdcd9c101 Author: xuelei Date: 2010-12-02 23:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e0bdcd9c101 6979376: to have ldap filters tolerate underscore character in object identifier Reviewed-by: weijun ! src/share/classes/com/sun/jndi/ldap/Filter.java ! test/com/sun/jndi/ldap/InvalidLdapFilters.java From joe.darcy at oracle.com Fri Dec 3 16:06:11 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 03 Dec 2010 08:06:11 -0800 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" Message-ID: <4CF91573.2070408@oracle.com> Hello. Please review this simple fix for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" http://cr.openjdk.java.net/~darcy/6990094.0/ The complete patch is --- old/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800 +++ new/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800 @@ -3498,8 +3498,8 @@ return ((int[]) array).clone(); } else if (array instanceof long[]) { return ((long[]) array).clone(); - } else if (array instanceof double[]) { - return ((double[]) array).clone(); + } else if (array instanceof short[]) { + return ((short[]) array).clone(); } else { throw new AssertionError(); } You'll notice there is no regression test for this change. One justification is that the fix is in the "obviously no bugs" category. [1] There is an if-else instanceof chain over Object arrays and arrays of each primitive type; there are two checks for double and none for short so changing the one of the double checks to short is "obviously correct." Also, I've taken a stab a writing an explicit regression test for this condition, but the problem only manifests in cases beyond my direct serialization experience where a class has overridden the readUnshared method. -Joe [1] "There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies." C.A.R. Hoare] From maurizio.cimadamore at oracle.com Fri Dec 3 16:34:14 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 03 Dec 2010 16:34:14 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101203163418.42FD347079@hg.openjdk.java.net> Changeset: 9359f4222545 Author: mcimadamore Date: 2010-12-03 16:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9359f4222545 6956758: NPE in com.sun.tools.javac.code.Symbol - isSubClass Summary: Use of TransTypes.cast() instead of TransTypes.coerce() causes NPE in Lower Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/6956758/T6956758neg.java + test/tools/javac/generics/6956758/T6956758neg.out + test/tools/javac/generics/6956758/T6956758pos.java Changeset: aa6605d883dc Author: mcimadamore Date: 2010-12-03 16:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aa6605d883dc 7002837: Diamond: javac generates diamond inference errors when in 'finder' mode Summary: Javac should disable error messages when analyzing instance creation expression in 'diamond finder' mode Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/7002837/T7002837.java From jim.holmlund at sun.com Fri Dec 3 21:49:30 2010 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 03 Dec 2010 21:49:30 +0000 Subject: hg: jdk7/tl/langtools: 6990209: JCK7-compiler lang/ICLS/icls006/icls00603/icls00603a.html#icls00603src test fails. Message-ID: <20101203214932.BC7DF4708A@hg.openjdk.java.net> Changeset: 91b4f44c9742 Author: jjh Date: 2010-12-03 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/91b4f44c9742 6990209: JCK7-compiler lang/ICLS/icls006/icls00603/icls00603a.html#icls00603src test fails. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java From mandy.chung at oracle.com Fri Dec 3 22:52:44 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 03 Dec 2010 14:52:44 -0800 Subject: Review request for 6977034 Thread.getState() very slow Message-ID: <4CF974BC.2030503@oracle.com> Fix for 6977034: Thread.getState() very slow Webrev at: http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ This is an improvement to map a Thread's threadStatus field to Thread.State. The VM updates the Thread.threadStatus field directly at state transition with the value as defined in JVM TI [1]. The java.lang.Thread.getState() implementation can directly access the threadStatus value and do a direct lookup from an array of Thread.State. The threadStatus value is a bit vector and we would have to create an array of a minimum of 1061 (0x425) elements to do direct mapping. I took the approach to use the first highest order bit set to 1 in the masked threadStatus value as the index to the Thread.State element and only caches 32 elements (could be fewer). I wrote a micro-benchmark measuring the Thread.getState of a thread in different state that shows 1.7X to 6X speedup (see below). There is possibly some issue with my micro-benchmark that I didn't observe the 14X speed up as Doug did in his experiment. However, I'd like to get this reviewed and pushed to the repository so that anyone can do more experiment on the performance measurement. Thanks Mandy P.S. The discussion on this thread can be found at [2] [3]. [1] http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html JDK 7 b120 (in ms) With fix (in ms) Speed up main 46465 22772 2.04 NEW 50676 29921 1.69 RUNNABLE 42202 14690 2.87 BLOCKED 72773 12296 5.92 WAITING 48811 13041 3.74 TIMED_WAITING 45737 12849 3.56 TERMINATED 40314 16376 2.46 -------------- next part -------------- An HTML attachment was scrubbed... URL: From assembling.signals at yandex.ru Fri Dec 3 23:03:30 2010 From: assembling.signals at yandex.ru (assembling signals) Date: Sat, 04 Dec 2010 00:03:30 +0100 Subject: b120 changelog empty? Message-ID: <510681291417410@web85.yandex.ru> Hello community! http://download.java.net/jdk7/changes/jdk7-b120.html The file exists since over one day, but stays empty. Does it mean: no changes? From forax at univ-mlv.fr Sat Dec 4 00:14:12 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 04 Dec 2010 01:14:12 +0100 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CF974BC.2030503@oracle.com> References: <4CF974BC.2030503@oracle.com> Message-ID: <4CF987D4.2020700@univ-mlv.fr> On 12/03/2010 11:52 PM, Mandy Chung wrote: > Fix for 6977034: Thread.getState() very slow > > Webrev at: > http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ Hi Mandy, you can use Integer.highestOneBit instead of the loop. Also, setMapElement should be a pure function, i.e without the side effect on array. In that case, setMapElement(map, JVMTI_THREAD_STATE_TERMINATED, TERMINATED); can be transformed to map[JVMTI_THREAD_STATE_TERMINATED] = highestJVMTIStateBit(TERMINATED); so the access to the array element is not far from the creation of the array so the VM can remove array bound checks even if highestJVMTIStateBit is not inlined. > > This is an improvement to map a Thread's threadStatus field to > Thread.State. The VM updates the Thread.threadStatus field directly > at state transition with the value as defined in JVM TI [1]. The > java.lang.Thread.getState() implementation can directly access the > threadStatus value and do a direct lookup from an array of > Thread.State. The threadStatus value is a bit vector and we would > have to create an array of a minimum of 1061 (0x425) elements to do > direct mapping. I took the approach to use the first highest order > bit set to 1 in the masked threadStatus value as the index to the > Thread.State element and only caches 32 elements (could be fewer). I > wrote a micro-benchmark measuring the Thread.getState of a thread in > different state that shows 1.7X to 6X speedup (see below). There is > possibly some issue with my micro-benchmark that I didn't observe the > 14X speed up as Doug did in his experiment. However, I'd like to get > this reviewed and pushed to the repository so that anyone can do more > experiment on the performance measurement. > > Thanks > Mandy > P.S. The discussion on this thread can be found at [2] [3]. > > [1] > http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html > > > JDK 7 b120 (in ms) With fix (in ms) Speed up > main 46465 22772 2.04 > NEW 50676 29921 1.69 > RUNNABLE 42202 14690 2.87 > BLOCKED 72773 12296 5.92 > WAITING 48811 13041 3.74 > TIMED_WAITING 45737 12849 3.56 > TERMINATED 40314 16376 2.46 > R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From eamonn.mcmanus at oracle.com Sat Dec 4 12:22:04 2010 From: eamonn.mcmanus at oracle.com (Eamonn McManus) Date: Sat, 04 Dec 2010 13:22:04 +0100 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CF974BC.2030503@oracle.com> References: <4CF974BC.2030503@oracle.com> Message-ID: <4CFA326C.1090500@oracle.com> An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Dec 5 07:27:13 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 05 Dec 2010 02:27:13 -0500 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFA326C.1090500@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> Message-ID: <4CFB3ED1.2060404@oracle.com> As Eamonn writes it, it will never cache miss but may frequently branch mispredict (possibly multiple times). If you do a shift + mask + index into a small table, it will cache miss most the time but never branch mispredict. (In a real program it will cache miss frequently since thread state calls are infrequent and the lookup table will fall out of cache; in a microbenchmark it will almost never cache miss as the lookup table will be hot.) On 12/4/2010 7:22 AM, Eamonn McManus wrote: > Hi Mandy, > > This test: > > if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) == 1) { > > is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 > helpfully flags this; I'm not sure if earlier versions do.) > > But, once corrected, I think you could use this idea further to write a much > simpler and faster method, on these lines: > > public static Thread.State toThreadState(int threadStatus) { > if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE)*!= 0*) { > return RUNNABLE; > } else if ((threadStatus& JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { > return BLOCKED; > } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) != 0) { > return TIMED_WAITING; > } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_INDEFINITELY) != 0) { > return WAITING; > } else if ((threadStatus& JVMTI_THREAD_STATE_TERMINATED) != 0) { > return TERMINATED; > } else { > return NEW; > } > } > > You could tweak the order of the tests based on what might be the relative > frequency of the different states but it probably isn't worth it. > > Regards, > > ?amonn > > > On 3/12/10 11:52 PM, Mandy Chung wrote: >> Fix for 6977034: Thread.getState() very slow >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >> >> This is an improvement to map a Thread's threadStatus field to Thread.State. >> The VM updates the Thread.threadStatus field directly at state transition >> with the value as defined in JVM TI [1]. The java.lang.Thread.getState() >> implementation can directly access the threadStatus value and do a direct >> lookup from an array of Thread.State. The threadStatus value is a bit vector >> and we would have to create an array of a minimum of 1061 (0x425) elements >> to do direct mapping. I took the approach to use the first highest order bit >> set to 1 in the masked threadStatus value as the index to the Thread.State >> element and only caches 32 elements (could be fewer). I wrote a >> micro-benchmark measuring the Thread.getState of a thread in different state >> that shows 1.7X to 6X speedup (see below). There is possibly some issue with >> my micro-benchmark that I didn't observe the 14X speed up as Doug did in his >> experiment. However, I'd like to get this reviewed and pushed to the >> repository so that anyone can do more experiment on the performance measurement. >> >> Thanks >> Mandy >> P.S. The discussion on this thread can be found at [2] [3]. >> >> [1] http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >> [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >> >> >> JDK 7 b120 (in ms) With fix (in ms) Speed up >> main 46465 22772 2.04 >> NEW 50676 29921 1.69 >> RUNNABLE 42202 14690 2.87 >> BLOCKED 72773 12296 5.92 >> WAITING 48811 13041 3.74 >> TIMED_WAITING 45737 12849 3.56 >> TERMINATED 40314 16376 2.46 >> From dalibor.topic at oracle.com Sun Dec 5 18:23:52 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sun, 05 Dec 2010 19:23:52 +0100 Subject: b120 changelog empty? In-Reply-To: <510681291417410@web85.yandex.ru> References: <510681291417410@web85.yandex.ru> Message-ID: <4CFBD8B8.80506@oracle.com> On 12/4/10 12:03 AM, assembling signals wrote: > Hello community! > > http://download.java.net/jdk7/changes/jdk7-b120.html > > The file exists since over one day, but stays empty. Looks fine to me: http://download.java.net/jdk7/changes/jdk7-b120.html http://hg.openjdk.java.net/jdk7/jdk7/corba Changeset Bug ID Synopsys f642c9ec81a0 6277781 Serialization of Enums over IIOP is broke. cff5a173ec1e 6763340 memory leak in com.sun.corba.se.* classes 6873605 Missing finishedDispatch() call in ORBImpl causes test failures after 5u20 b04 http://hg.openjdk.java.net/jdk7/jdk7/hotspot Changeset Bug ID Synopsys 5484e7c53fa7 6997698 Bump the HS20 build number to 03 http://hg.openjdk.java.net/jdk7/jdk7/jdk Changeset Bug ID Synopsys 809ec4b6eb88 6862652 A number of tests fail for some background Themes configured on Windows7 & Windows 2008R2 in 6u15 f6f2989e547f 6988428 Shape is not applied sometimes 9c7c5ecea41a 6960655 GTKFileDialogPeer shouldn't be a singletone 65bd45308475 6984039 awt source rebranding vendor changes needed (jdk7 only) 4c5aa2af3540 6989505 java.awt.Robot's getPixelColor treats not fully opaque Window as fully transparent. 8e4806e40a25 6960516 sun.awt.UngrabEvent has an ID over AWTEvent.RESERVED_ID_MAX 77b3011bc882 6877895 Some AWT's methods should specify throwing NPE for null arg value 286b14273037 6899877 JComponent.add/removeNotify() should mention that they are not supposed to be called directly d385b33c0db0 6613904 javax.swing.GroupLayout.createParallelGroup(..) doesn't throw IllegalArgumentException for null arg d449b91c56b6 6771184 Some methods in text package don't throw BadLocationException when expected 25c7ef39e22a 6987844 Incorrect width of JComboBox drop down 4983c4edc535 6720170 ByteArrayInputStream.skip(long) can overflow internally bc7d400cd749 6985875 Change servicetags registration to refer to Oracle SSO and MSO 5.2 release 8e5c27614fec 6988618 JCK test setDaemon0101 hangs on specific machine aed81a97aae3 6696028 JMXServiceURL like service:jmx:rmi:///jndi/iiop:// should be rejected by the RMI conn provider. 6984520 NPE IN RMIConnector.connect 5de001f5f8b4 6957378 JMX memory leak dd3afa184407 6985763 Pack200.Packer.pack(...) and Pack200.Unpacker.unpack(...) throw unspecified exceptions 856843c444a0 6997740 ktab entry related test compilation error 34faa22a8ce8 6994717 expired certificate in test ValidateCertPath a12112af843c 6792706 Add JAR file to bootclasspath when using AggressiveOpts e27ad63b0f54 6952519 kdc_timeout is not being honoured when using TCP 00d9ecc5dceb 6998250 Remove redundant src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java c164d0d59465 6979009 (fc) FileChannel.read() fails to throw ClosedByInterruptException 4565d120e514 6987827 security/util/Resources.java needs improvement aab6e875eb52 6465367 (coll) Typo in TreeMap documentation af2de4de1076 6982530 javadoc update to SyncFactory & JdbcResource bundle for synchronization issues 1e7dc87fad95 6960894 Better AS-REQ creation and processing c4a38022fdc1 6999086 Clarify that SyncFactory.setLogger can throw an NullPointerException e1a1a2f5d7e1 6991528 Support making Throwable.suppressedExceptions immutable f88048284eb6 6999915 TEST_BUG: test/java/nio/channels/AsynchronousSocketChannel/Leaky.java failed intermittently (win) bf284d2db008 6993789 LinkedBlockingDeque iterator/descendingIterator loops and owns lock forever 0682c9357897 6994145 (zipfs) README should be updated 6994161 (zipfs) newFileSystem method should FileSystemAlreadyExistsException 6994152 (zipfs) copyTo ignores COPY_ATTRIBUTES option 23ccf9a8451f 6544278 SecurityException not thrown for Indexed Jar file whose signature is corrupted 37d74e29687c 7003227 (pack200) intermittent failures compiling pack200 http://hg.openjdk.java.net/jdk7/jdk7/langtools Changeset Bug ID Synopsys f2048d9c666e 6993963 Project Coin: Use precise exception analysis for effectively final catch parameters e9e41c88b03e 6714835 Safe cast is rejected (with warning) by javac 9427a3c795fc 6998063 new Scope impl to fix Scope performance issues a0d9d642f65b 6997958 test tools/javac/api/T6412669.java fails in PIT bce19889597e 6996914 Diamond inference: problem when accessing protected constructor 58ceeff50af8 6598108 com.sun.source.util.Trees.isAccessible incorrect fdc67f5170e9 6999067 cast for invokeExact call gets redundant cast to warnings 6a99b741a1b0 6970016 Clean up ARM/try-with-resources implementation 4328728e0409 6991528 Support making Throwable.suppressedExceptions immutable a7ea58fa3e9a 6985719 Alike methods in interfaces (Inheritance and Overriding) 1dd813a529cf 6999635 Multicatch: crash while compiling simple code with a multicatch parameter cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From eamonn.mcmanus at oracle.com Sun Dec 5 19:00:11 2010 From: eamonn.mcmanus at oracle.com (Eamonn McManus) Date: Sun, 05 Dec 2010 20:00:11 +0100 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFB3ED1.2060404@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFB3ED1.2060404@oracle.com> Message-ID: <4CFBE13B.7010807@oracle.com> An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sun Dec 5 20:22:42 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 05 Dec 2010 15:22:42 -0500 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFBE13B.7010807@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFB3ED1.2060404@oracle.com> <4CFBE13B.7010807@oracle.com> Message-ID: <4CFBF492.60708@oracle.com> Its worth noting that the real performance offender here is that thread states are enums (and therefore object references). If they were integers, then the entire thing could most likely be done in a way that is guaranteed branch-free and dcache-miss-free. Agree with Eamonn that the current sequence-of-tests is probably good enough. Might be worth doing a little profiling to choose optimal order of tests; I would guess that the right order is RUNNABLE, WAITING, TIMED_WAITING, BLOCKED, NEW, TERMINATED, but that's just an OOMH (out-of-my-hat) guess. There are probably not enough bits here to justify a binary search (which trades off best-case against average/worst-case time, but might turn up a combination of bits that has better branch prediction characteristics.) On 12/5/2010 2:00 PM, Eamonn McManus wrote: > Yeah, it was a bit blithe of me to write that the sequence of tests was > faster. In the table-lookup version, if you get rid of the initial test for > RUNNABLE, and if you use Integer.numberOfLeadingZeros, and if the JIT compiler > intrinsifies that to a native processor instruction, and if the lookup table > is in L1 cache, then the table-lookup version will run in constant time and be > better than the worst case of the sequence-of-tests version, and probably > better than the average case too. But, as you say, that last /if/ (the cache > hit) will usually not be true, and in that case I would not be surprised if > the sequence of tests were faster even in its worst case. > > Anyway the sequence-of-tests version is unquestionably simpler, and I would > venture that the best solution is probably to go with that, plus a new method > in the API that explicitly tests whether a thread is runnable. That's trivial > to implement now that Mandy has pulled the knowledge of state bits into the > Java code rather than being hidden in the bowels of the VM; and its > implementation will be faster than (Thread.getState() == RUNNABLE) regardless > of the implementation of the latter. > > ?amonn > > > On 5/12/10 8:27 AM, Brian Goetz wrote: >> As Eamonn writes it, it will never cache miss but may frequently branch >> mispredict (possibly multiple times). If you do a shift + mask + index into >> a small table, it will cache miss most the time but never branch mispredict. >> (In a real program it will cache miss frequently since thread state calls >> are infrequent and the lookup table will fall out of cache; in a >> microbenchmark it will almost never cache miss as the lookup table will be >> hot.) >> >> On 12/4/2010 7:22 AM, Eamonn McManus wrote: >>> Hi Mandy, >>> >>> This test: >>> >>> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) == 1) { >>> >>> is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 >>> helpfully flags this; I'm not sure if earlier versions do.) >>> >>> But, once corrected, I think you could use this idea further to write a much >>> simpler and faster method, on these lines: >>> >>> public static Thread.State toThreadState(int threadStatus) { >>> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE)*!= 0*) { >>> return RUNNABLE; >>> } else if ((threadStatus& >>> JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { >>> return BLOCKED; >>> } else if ((threadStatus& >>> JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) != 0) { >>> return TIMED_WAITING; >>> } else if ((threadStatus& >>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY) != 0) { >>> return WAITING; >>> } else if ((threadStatus& JVMTI_THREAD_STATE_TERMINATED) != 0) { >>> return TERMINATED; >>> } else { >>> return NEW; >>> } >>> } >>> >>> You could tweak the order of the tests based on what might be the relative >>> frequency of the different states but it probably isn't worth it. >>> >>> Regards, >>> >>> ?amonn >>> >>> >>> On 3/12/10 11:52 PM, Mandy Chung wrote: >>>> Fix for 6977034: Thread.getState() very slow >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >>>> >>>> This is an improvement to map a Thread's threadStatus field to Thread.State. >>>> The VM updates the Thread.threadStatus field directly at state transition >>>> with the value as defined in JVM TI [1]. The java.lang.Thread.getState() >>>> implementation can directly access the threadStatus value and do a direct >>>> lookup from an array of Thread.State. The threadStatus value is a bit vector >>>> and we would have to create an array of a minimum of 1061 (0x425) elements >>>> to do direct mapping. I took the approach to use the first highest order bit >>>> set to 1 in the masked threadStatus value as the index to the Thread.State >>>> element and only caches 32 elements (could be fewer). I wrote a >>>> micro-benchmark measuring the Thread.getState of a thread in different state >>>> that shows 1.7X to 6X speedup (see below). There is possibly some issue with >>>> my micro-benchmark that I didn't observe the 14X speed up as Doug did in his >>>> experiment. However, I'd like to get this reviewed and pushed to the >>>> repository so that anyone can do more experiment on the performance >>>> measurement. >>>> >>>> Thanks >>>> Mandy >>>> P.S. The discussion on this thread can be found at [2] [3]. >>>> >>>> [1] >>>> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >>>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >>>> [3] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >>>> >>>> >>>> JDK 7 b120 (in ms) With fix (in ms) Speed up >>>> main 46465 22772 2.04 >>>> NEW 50676 29921 1.69 >>>> RUNNABLE 42202 14690 2.87 >>>> BLOCKED 72773 12296 5.92 >>>> WAITING 48811 13041 3.74 >>>> TIMED_WAITING 45737 12849 3.56 >>>> TERMINATED 40314 16376 2.46 >>>> From weijun.wang at oracle.com Sun Dec 5 22:49:53 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sun, 05 Dec 2010 22:49:53 +0000 Subject: hg: jdk7/tl/jdk: 7004721: ktarg.sh fails when there's no default realm Message-ID: <20101205225003.5830247132@hg.openjdk.java.net> Changeset: e3dbb8cd8820 Author: weijun Date: 2010-12-06 06:49 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e3dbb8cd8820 7004721: ktarg.sh fails when there's no default realm Reviewed-by: xuelei ! test/sun/security/krb5/tools/ktarg.sh From David.Holmes at oracle.com Sun Dec 5 22:58:48 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 06 Dec 2010 08:58:48 +1000 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFBF492.60708@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFB3ED1.2060404@oracle.com> <4CFBE13B.7010807@oracle.com> <4CFBF492.60708@oracle.com> Message-ID: <4CFC1928.5000408@oracle.com> Brian Goetz said the following on 12/06/10 06:22: > Its worth noting that the real performance offender here is that thread > states are enums (and therefore object references). If they were > integers, then the entire thing could most likely be done in a way that > is guaranteed branch-free and dcache-miss-free. > > Agree with Eamonn that the current sequence-of-tests is probably good > enough. Might be worth doing a little profiling to choose optimal order > of tests; I would guess that the right order is RUNNABLE, WAITING, > TIMED_WAITING, BLOCKED, NEW, TERMINATED, but that's just an OOMH > (out-of-my-hat) guess. I had already had this discussion with Mandy, including the idea that a lookup table would be faster - if there were a simple way to construct it. The current order of tests is based on our discussion. No doubt Runnable should be first, and new/terminated last. The rest of somewhat subjective. As sync is used more than wait/notify then BLOCKED would be next most likely. For waiting vs timed-waiting it depends on how defensively people code their waits :) Anyway, this was all premised on slow performance that Doug observed as part of ForkJoin mechanics. It would be good to hear back from him on how this updated approach performs. If the FJ code has changed such that this is no longer an issue then I would suggest that Mandy's changes are "good enough" and we let her move on. Cheers, David There are probably not enough bits here to > justify a binary search (which trades off best-case against > average/worst-case time, but might turn up a combination of bits that > has better branch prediction characteristics.) > > > On 12/5/2010 2:00 PM, Eamonn McManus wrote: >> Yeah, it was a bit blithe of me to write that the sequence of tests was >> faster. In the table-lookup version, if you get rid of the initial >> test for >> RUNNABLE, and if you use Integer.numberOfLeadingZeros, and if the JIT >> compiler >> intrinsifies that to a native processor instruction, and if the lookup >> table >> is in L1 cache, then the table-lookup version will run in constant >> time and be >> better than the worst case of the sequence-of-tests version, and probably >> better than the average case too. But, as you say, that last /if/ (the >> cache >> hit) will usually not be true, and in that case I would not be >> surprised if >> the sequence of tests were faster even in its worst case. >> >> Anyway the sequence-of-tests version is unquestionably simpler, and I >> would >> venture that the best solution is probably to go with that, plus a new >> method >> in the API that explicitly tests whether a thread is runnable. That's >> trivial >> to implement now that Mandy has pulled the knowledge of state bits >> into the >> Java code rather than being hidden in the bowels of the VM; and its >> implementation will be faster than (Thread.getState() == RUNNABLE) >> regardless >> of the implementation of the latter. >> >> ?amonn >> >> >> On 5/12/10 8:27 AM, Brian Goetz wrote: >>> As Eamonn writes it, it will never cache miss but may frequently branch >>> mispredict (possibly multiple times). If you do a shift + mask + >>> index into >>> a small table, it will cache miss most the time but never branch >>> mispredict. >>> (In a real program it will cache miss frequently since thread state >>> calls >>> are infrequent and the lookup table will fall out of cache; in a >>> microbenchmark it will almost never cache miss as the lookup table >>> will be >>> hot.) >>> >>> On 12/4/2010 7:22 AM, Eamonn McManus wrote: >>>> Hi Mandy, >>>> >>>> This test: >>>> >>>> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) == 1) { >>>> >>>> is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 >>>> helpfully flags this; I'm not sure if earlier versions do.) >>>> >>>> But, once corrected, I think you could use this idea further to >>>> write a much >>>> simpler and faster method, on these lines: >>>> >>>> public static Thread.State toThreadState(int threadStatus) { >>>> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE)*!= 0*) { >>>> return RUNNABLE; >>>> } else if ((threadStatus& >>>> JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { >>>> return BLOCKED; >>>> } else if ((threadStatus& >>>> JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) != 0) { >>>> return TIMED_WAITING; >>>> } else if ((threadStatus& >>>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY) != 0) { >>>> return WAITING; >>>> } else if ((threadStatus& JVMTI_THREAD_STATE_TERMINATED) >>>> != 0) { >>>> return TERMINATED; >>>> } else { >>>> return NEW; >>>> } >>>> } >>>> >>>> You could tweak the order of the tests based on what might be the >>>> relative >>>> frequency of the different states but it probably isn't worth it. >>>> >>>> Regards, >>>> >>>> ?amonn >>>> >>>> >>>> On 3/12/10 11:52 PM, Mandy Chung wrote: >>>>> Fix for 6977034: Thread.getState() very slow >>>>> >>>>> Webrev at: >>>>> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >>>>> >>>>> This is an improvement to map a Thread's threadStatus field to >>>>> Thread.State. >>>>> The VM updates the Thread.threadStatus field directly at state >>>>> transition >>>>> with the value as defined in JVM TI [1]. The >>>>> java.lang.Thread.getState() >>>>> implementation can directly access the threadStatus value and do a >>>>> direct >>>>> lookup from an array of Thread.State. The threadStatus value is a >>>>> bit vector >>>>> and we would have to create an array of a minimum of 1061 (0x425) >>>>> elements >>>>> to do direct mapping. I took the approach to use the first highest >>>>> order bit >>>>> set to 1 in the masked threadStatus value as the index to the >>>>> Thread.State >>>>> element and only caches 32 elements (could be fewer). I wrote a >>>>> micro-benchmark measuring the Thread.getState of a thread in >>>>> different state >>>>> that shows 1.7X to 6X speedup (see below). There is possibly some >>>>> issue with >>>>> my micro-benchmark that I didn't observe the 14X speed up as Doug >>>>> did in his >>>>> experiment. However, I'd like to get this reviewed and pushed to the >>>>> repository so that anyone can do more experiment on the performance >>>>> measurement. >>>>> >>>>> Thanks >>>>> Mandy >>>>> P.S. The discussion on this thread can be found at [2] [3]. >>>>> >>>>> [1] >>>>> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >>>>> >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >>>>> >>>>> [3] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >>>>> >>>>> >>>>> >>>>> JDK 7 b120 (in ms) With fix (in ms) Speed up >>>>> main 46465 22772 2.04 >>>>> NEW 50676 29921 1.69 >>>>> RUNNABLE 42202 14690 2.87 >>>>> BLOCKED 72773 12296 5.92 >>>>> WAITING 48811 13041 3.74 >>>>> TIMED_WAITING 45737 12849 3.56 >>>>> TERMINATED 40314 16376 2.46 >>>>> From dl at cs.oswego.edu Sun Dec 5 23:25:27 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 05 Dec 2010 18:25:27 -0500 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFC1928.5000408@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFB3ED1.2060404@oracle.com> <4CFBE13B.7010807@oracle.com> <4CFBF492.60708@oracle.com> <4CFC1928.5000408@oracle.com> Message-ID: <4CFC1F67.4060007@cs.oswego.edu> On 12/05/10 17:58, David Holmes wrote: > Anyway, this was all premised on slow performance that Doug observed as part of > ForkJoin mechanics. It would be good to hear back from him on how this updated > approach performs. If the FJ code has changed such that this is no longer an > issue then I would suggest that Mandy's changes are "good enough" and we let her > move on. Sorry for a non-answer: I long ago reworked ForkJoin to not use this because it was much too slow. (Sorry, I can't easily reconstruct version using it to check changes.) If it were improved enough to run in only a few cycles I might start using it routinely. If it were in-between, I might use it in a different way as a backup strategy. -Doug From lana.steuck at oracle.com Mon Dec 6 00:09:09 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:09:09 +0000 Subject: hg: jdk7/tl/corba: 4 new changesets Message-ID: <20101206000912.92C7947136@hg.openjdk.java.net> Changeset: 4ab3c663d147 Author: cl Date: 2010-12-02 19:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/4ab3c663d147 Added tag jdk7-b120 for changeset cff5a173ec1e ! .hgtags Changeset: dc903ccc6219 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/dc903ccc6219 Added tag jdk7-b119 for changeset 39829414ae31 ! .hgtags Changeset: 2cc9f3299210 Author: ohair Date: 2010-12-03 19:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2cc9f3299210 Merge ! .hgtags Changeset: e6f42f5d6d60 Author: lana Date: 2010-12-05 15:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e6f42f5d6d60 Merge From lana.steuck at oracle.com Mon Dec 6 00:11:54 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:11:54 +0000 Subject: hg: jdk7/tl: 9 new changesets Message-ID: <20101206001155.1C27247137@hg.openjdk.java.net> Changeset: 8b474f74f0cc Author: herrick Date: 2010-10-08 11:43 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/8b474f74f0cc Merge Changeset: 734a599c6ffc Author: igor Date: 2010-10-14 16:44 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/734a599c6ffc Merge Changeset: 2fae5a0f6c72 Author: herrick Date: 2010-10-16 12:31 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2fae5a0f6c72 Merge Changeset: 0f94b06d1a3d Author: herrick Date: 2010-10-22 14:13 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/0f94b06d1a3d Merge Changeset: 474f0e1f64aa Author: herrick Date: 2010-10-29 16:00 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/474f0e1f64aa Merge Changeset: 2c6010a2deec Author: jqzuo Date: 2010-11-05 13:39 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2c6010a2deec Merge Changeset: 661360bef6cc Author: jqzuo Date: 2010-11-15 14:17 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/661360bef6cc Merge Changeset: 366ff0b6d215 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/366ff0b6d215 Added tag jdk7-b119 for changeset 661360bef6cc ! .hgtags Changeset: 6f79b68d1851 Author: cl Date: 2010-12-02 19:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6f79b68d1851 Added tag jdk7-b120 for changeset 366ff0b6d215 ! .hgtags From lana.steuck at oracle.com Mon Dec 6 00:12:22 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:12:22 +0000 Subject: hg: jdk7/tl/hotspot: 35 new changesets Message-ID: <20101206001326.1DF7A47138@hg.openjdk.java.net> Changeset: d4681dc64964 Author: trims Date: 2010-11-11 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d4681dc64964 Added tag hs20-b02 for changeset 3ef7426b4dea ! .hgtags Changeset: 31aff7f873c6 Author: trims Date: 2010-11-10 21:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/31aff7f873c6 Merge Changeset: 42a10fc37986 Author: roland Date: 2010-10-15 09:38 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/42a10fc37986 6991577: add IfOp optimization to C1 Summary: Ifop optimization for c1 Reviewed-by: never, phh, iveresov ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: e5c3d73017ab Author: roland Date: 2010-10-15 02:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e5c3d73017ab Merge Changeset: 7aff5786cc02 Author: twisti Date: 2010-10-18 01:54 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7aff5786cc02 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC Reviewed-by: kvn, jrose, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! test/Makefile + test/compiler/6991596/Test6991596.java Changeset: 0357ff4bd6b2 Author: never Date: 2010-10-18 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0357ff4bd6b2 Merge Changeset: 87d6a4d1ecbc Author: twisti Date: 2010-10-19 02:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87d6a4d1ecbc 6990192: VM crashes in ciTypeFlow::get_block_for() Reviewed-by: never ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/runtime/thread.cpp Changeset: cd4e20dc9917 Author: twisti Date: 2010-10-20 04:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd4e20dc9917 Merge ! src/share/vm/runtime/thread.cpp Changeset: ce6848d0666d Author: never Date: 2010-10-19 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ce6848d0666d 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: f8aaf8522a6b Author: never Date: 2010-10-20 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f8aaf8522a6b Merge Changeset: 1e9a9d2e6509 Author: never Date: 2010-10-21 11:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1e9a9d2e6509 6970683: improvements to hs_err output Reviewed-by: kvn, jrose, dholmes, coleenp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp Changeset: f195c4737aca Author: twisti Date: 2010-10-22 03:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f195c4737aca 6994130: Zero PowerPC fix Summary: 6953477 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/runtime/frame.cpp Changeset: d2e35ffae982 Author: twisti Date: 2010-10-28 00:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d2e35ffae982 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic Summary: The logic of ClassFileParser::java_dyn_MethodHandle_fix_pre needs to take care of an already changed vmentry signature. Reviewed-by: never, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp Changeset: d1896d1dda3e Author: jrose Date: 2010-10-30 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d1896d1dda3e 6981788: GC map generator sometimes picks up the wrong kind of instruction operand Summary: Distinguish pool indexes from cache indexes in recently changed code. Reviewed-by: never ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp Changeset: fff777a71346 Author: jrose Date: 2010-10-30 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fff777a71346 6994093: MethodHandle.invokeGeneric needs porting to SPARC Summary: SPARC code missing from fix to 6939224 Reviewed-by: twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp Changeset: 8213b0f5c92d Author: jrose Date: 2010-10-30 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8213b0f5c92d 6981777: implement JSR 292 EG adjustments from summer 2010 Summary: Small bug fix to make "raw" adapters work for JDK changes under 6981777 Reviewed-by: twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 3b2dea75431e Author: jrose Date: 2010-10-30 13:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3b2dea75431e 6984311: JSR 292 needs optional bootstrap method parameters Summary: Allow CONSTANT_InvokeDynamic nodes to have any number of extra operands. Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodComparator.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: ae065c367d93 Author: kvn Date: 2010-11-02 09:00 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ae065c367d93 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. Summary: Use hardware DIV instruction for long division by constant when it is faster than code with multiply. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/matcher.hpp Changeset: 885e464e1a40 Author: twisti Date: 2010-11-02 14:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/885e464e1a40 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad Changeset: e62345fd6a46 Author: twisti Date: 2010-11-04 12:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e62345fd6a46 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted Reviewed-by: kvn, jrose, never ! src/cpu/sparc/vm/methodHandles_sparc.cpp Changeset: f42a2f0c16bb Author: jrose Date: 2010-11-05 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f42a2f0c16bb 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands Summary: Add missing line to vmStructs. Also fix bug with class dumper. Reviewed-by: twisti, kvn ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 34bd82eba3bb Author: iveresov Date: 2010-11-05 14:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/34bd82eba3bb 6997456: Not possible to build just compiler2 Summary: Fix the compiler error. Allow to build just c2 specifying FORCE_TIERED=0 on the command line. Reviewed-by: never, kvn ! make/linux/Makefile ! make/solaris/Makefile ! make/windows/build.make ! src/share/vm/runtime/java.cpp Changeset: d0895dfaf7cc Author: iveresov Date: 2010-11-06 02:53 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d0895dfaf7cc Merge Changeset: 2fe998383789 Author: kvn Date: 2010-11-06 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2fe998383789 6997311: SIGFPE in new long division asm code Summary: use unsigned DIV instruction Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! test/compiler/6603011/Test.java Changeset: e4fcbeb5a698 Author: kvn Date: 2010-11-06 20:35 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e4fcbeb5a698 6991188: C2 Crashes while compiling method Summary: Do several iterations to build EA Connection Graph. Reviewed-by: never, twisti, ysr ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 5caa30ea147b Author: iveresov Date: 2010-11-08 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5caa30ea147b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/thread.cpp Changeset: 2db84614f61d Author: iveresov Date: 2010-11-09 15:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2db84614f61d 6998737: JSR 292: Remove the plug guarding the use of compressed oops Summary: The plug that guards the use of compressed oops with invokedynamic needs to be removed Reviewed-by: twisti, kvn ! src/share/vm/runtime/arguments.cpp Changeset: b0e6879e48fa Author: kvn Date: 2010-11-09 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b0e6879e48fa 6839891: Array overrun in vm ci Summary: fix index check Reviewed-by: never ! src/share/vm/ci/ciInstanceKlass.cpp Changeset: 84d114b9170e Author: iveresov Date: 2010-11-11 17:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/84d114b9170e Merge Changeset: a1e319b5b13a Author: trims Date: 2010-11-11 23:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a1e319b5b13a Merge Changeset: 5484e7c53fa7 Author: trims Date: 2010-11-11 23:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5484e7c53fa7 6997698: Bump the HS20 build number to 03 Summary: Update the HS20 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f5603a6e5042 Author: lana Date: 2010-11-17 22:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f5603a6e5042 Merge Changeset: 18134a5c6da5 Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/18134a5c6da5 Added tag jdk7-b120 for changeset f5603a6e5042 ! .hgtags Changeset: 073378594ec6 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/073378594ec6 Added tag jdk7-b119 for changeset 5484e7c53fa7 ! .hgtags Changeset: 3f3653ab7af8 Author: ohair Date: 2010-12-03 19:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f3653ab7af8 Merge ! .hgtags From lana.steuck at oracle.com Mon Dec 6 00:14:34 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:14:34 +0000 Subject: hg: jdk7/tl/jaxws: 3 new changesets Message-ID: <20101206001434.51A9D4713B@hg.openjdk.java.net> Changeset: a4f2e1ca6716 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/a4f2e1ca6716 Added tag jdk7-b119 for changeset 41fa02b36637 ! .hgtags Changeset: aff278ea6189 Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/aff278ea6189 Added tag jdk7-b120 for changeset a4f2e1ca6716 ! .hgtags Changeset: 76ea68d0ffa2 Author: lana Date: 2010-12-05 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/76ea68d0ffa2 Merge From lana.steuck at oracle.com Mon Dec 6 00:16:44 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:16:44 +0000 Subject: hg: jdk7/tl/jdk: 25 new changesets Message-ID: <20101206002059.8E7ED4713C@hg.openjdk.java.net> Changeset: 4b09cad8528d Author: lana Date: 2010-11-02 22:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b09cad8528d Merge ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 0fc9955d603f Author: lana Date: 2010-11-11 18:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0fc9955d603f Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: 809ec4b6eb88 Author: jgodinez Date: 2010-11-15 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/809ec4b6eb88 6862652: A number of tests fail for some background Themes configured on Windows7 & Windows 2008R2 in 6u15 Reviewed-by: igor, prr ! test/sun/java2d/GdiRendering/InsetClipping.java ! test/sun/java2d/SunGraphics2D/DrawImageBilinear.java ! test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java Changeset: f6f2989e547f Author: anthony Date: 2010-11-08 17:51 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f6f2989e547f 6988428: Shape is not applied sometimes Summary: Always call ::SetWindowRgn() on the toolkit thread Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java Changeset: 9c7c5ecea41a Author: anthony Date: 2010-11-08 18:02 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c7c5ecea41a 6960655: GTKFileDialogPeer shouldn't be a singletone Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h Changeset: 65bd45308475 Author: art Date: 2010-11-09 14:02 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/65bd45308475 6984039: awt source rebranding vendor changes needed (jdk7 only) Reviewed-by: prr, ohair ! src/solaris/native/sun/awt/awt_MToolkit.c ! src/solaris/native/sun/awt/fontpath.c ! src/solaris/native/sun/xawt/XWindow.c Changeset: 4c5aa2af3540 Author: anthony Date: 2010-11-09 19:28 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c5aa2af3540 6989505: java.awt.Robot's getPixelColor treats not fully opaque Window as fully transparent. Summary: Use ::CreateDC() instead of ::GetDC() Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Robot.cpp Changeset: 8e4806e40a25 Author: dav Date: 2010-11-10 10:38 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8e4806e40a25 6960516: sun.awt.UngrabEvent has an ID over AWTEvent.RESERVED_ID_MAX Reviewed-by: dcherepanov, art ! src/share/classes/sun/awt/UngrabEvent.java + test/java/awt/event/OtherEvents/UngrabID/UngrabID.java Changeset: 77b3011bc882 Author: dcherepanov Date: 2010-11-11 15:27 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77b3011bc882 6877895: Some AWT's methods should specify throwing NPE for null arg value Reviewed-by: art, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/Window.java Changeset: b2e5858615d2 Author: lana Date: 2010-11-12 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b2e5858615d2 Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: 60a5739f97c5 Author: lana Date: 2010-11-15 18:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/60a5739f97c5 Merge Changeset: 9491a74b842e Author: lana Date: 2010-11-03 14:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9491a74b842e Merge ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 74f844c02cdd Author: lana Date: 2010-11-12 10:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74f844c02cdd Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: 286b14273037 Author: rupashka Date: 2010-11-13 13:04 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/286b14273037 6899877: JComponent.add/removeNotify() should mention that they are not supposed to be called directly Reviewed-by: alexp ! src/share/classes/javax/swing/JComponent.java Changeset: d385b33c0db0 Author: rupashka Date: 2010-11-13 19:22 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d385b33c0db0 6613904: javax.swing.GroupLayout.createParallelGroup(..) doesn't throw IllegalArgumentException for null arg Reviewed-by: peterz ! src/share/classes/javax/swing/GroupLayout.java + test/javax/swing/GroupLayout/6613904/bug6613904.java Changeset: d449b91c56b6 Author: rupashka Date: 2010-11-13 19:31 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d449b91c56b6 6771184: Some methods in text package don't throw BadLocationException when expected Reviewed-by: peterz ! src/share/classes/javax/swing/text/DefaultHighlighter.java + test/javax/swing/text/DefaultHighlighter/6771184/bug6771184.java Changeset: 25c7ef39e22a Author: alexp Date: 2010-11-15 19:50 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25c7ef39e22a 6987844: Incorrect width of JComboBox drop down Reviewed-by: anthony ! src/share/classes/javax/swing/Popup.java + test/javax/swing/JPopupMenu/6987844/bug6987844.java Changeset: 311457b67702 Author: lana Date: 2010-11-15 19:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/311457b67702 Merge Changeset: bd75fc38a82a Author: lana Date: 2010-11-15 19:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd75fc38a82a Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 37d74e29687c Author: ksrini Date: 2010-11-29 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/37d74e29687c 7003227: (pack200) intermittent failures compiling pack200 Reviewed-by: jjg ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/CodingMethod.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java Changeset: d4eda9a6328e Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d4eda9a6328e Added tag jdk7-b120 for changeset 37d74e29687c ! .hgtags Changeset: 320c5f5906a1 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/320c5f5906a1 Added tag jdk7-b119 for changeset ecab7eefb8f2 ! .hgtags Changeset: c80287e4d606 Author: ohair Date: 2010-12-03 19:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c80287e4d606 Merge ! .hgtags Changeset: f32b03dc4e76 Author: lana Date: 2010-12-05 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f32b03dc4e76 Merge Changeset: 51dd8df77406 Author: lana Date: 2010-12-05 16:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51dd8df77406 Merge From lana.steuck at oracle.com Mon Dec 6 00:22:54 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:22:54 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20101206002304.498A84713D@hg.openjdk.java.net> Changeset: 621e096ca843 Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/621e096ca843 Added tag jdk7-b120 for changeset 1dd813a529cf ! .hgtags Changeset: fb79ba6eb2e1 Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fb79ba6eb2e1 Added tag jdk7-b119 for changeset 814561077c44 ! .hgtags Changeset: d53cf2e9ad6c Author: ohair Date: 2010-12-03 19:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d53cf2e9ad6c Merge ! .hgtags Changeset: d53b87e07b13 Author: lana Date: 2010-12-05 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d53b87e07b13 Merge From lana.steuck at oracle.com Mon Dec 6 00:14:28 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 06 Dec 2010 00:14:28 +0000 Subject: hg: jdk7/tl/jaxp: 3 new changesets Message-ID: <20101206001429.1293247139@hg.openjdk.java.net> Changeset: 4821de0908de Author: cl Date: 2010-11-22 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/4821de0908de Added tag jdk7-b119 for changeset 9ee900f01c58 ! .hgtags Changeset: c3a09068ab6c Author: cl Date: 2010-12-02 19:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c3a09068ab6c Added tag jdk7-b120 for changeset 4821de0908de ! .hgtags Changeset: 46ef275f0d5a Author: lana Date: 2010-12-05 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/46ef275f0d5a Merge From weijun.wang at oracle.com Mon Dec 6 02:52:46 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 06 Dec 2010 02:52:46 +0000 Subject: hg: jdk7/tl/jdk: 5 new changesets Message-ID: <20101206025342.B00B147143@hg.openjdk.java.net> Changeset: b8713c88c060 Author: weijun Date: 2010-12-06 10:46 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8713c88c060 7004035: signed jar with only META-INF/* inside is not verifiable Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh + test/sun/security/tools/jarsigner/onlymanifest.sh Changeset: 6fc2e1efcb9a Author: weijun Date: 2010-12-06 10:46 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6fc2e1efcb9a 7004168: jarsigner -verify checks for KeyUsage codesigning ext on all certs instead of just signing cert Reviewed-by: mullan ! src/share/classes/sun/security/tools/JarSigner.java + test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 44d950400047 Author: weijun Date: 2010-12-06 10:48 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44d950400047 6896700: Validation of signatures succeed when it should fail Reviewed-by: wetmore ! src/share/classes/sun/security/rsa/RSASignature.java + test/sun/security/rsa/InvalidBitString.java ! test/sun/security/rsa/TestKeyPairGenerator.java Changeset: c338757f2bc0 Author: weijun Date: 2010-12-06 10:48 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c338757f2bc0 6943352: SSL regression: RSAClientKeyExchange fails to pass securerandom arg to KeyGen Reviewed-by: wetmore, xuelei ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 403785dc4493 Author: weijun Date: 2010-12-06 10:48 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/403785dc4493 6992964: FindBugs warnings in com.sun.security.auth.module.UnixSystem.java Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java From jonathan.gibbons at oracle.com Mon Dec 6 04:47:25 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 06 Dec 2010 04:47:25 +0000 Subject: hg: jdk7/tl/jdk: 7004021: docs should not assume -source 1.5 Message-ID: <20101206044742.39F6747149@hg.openjdk.java.net> Changeset: fe9ead37938c Author: jjg Date: 2010-12-05 20:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fe9ead37938c 7004021: docs should not assume -source 1.5 Reviewed-by: ohair ! make/docs/Makefile From pcj at roundroom.net Mon Dec 6 07:30:18 2010 From: pcj at roundroom.net (Peter Jones) Date: Mon, 6 Dec 2010 02:30:18 -0500 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: <4CF91573.2070408@oracle.com> References: <4CF91573.2070408@oracle.com> Message-ID: Joe, On Dec 3, 2010, at 11:06 AM, Joe Darcy wrote: > Please review this simple fix for > > 6990094 "ObjectInputStream cloneArray doesn't handle short[]" > http://cr.openjdk.java.net/~darcy/6990094.0/ > > The complete patch is > > --- old/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800 > +++ new/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800 > @@ -3498,8 +3498,8 @@ > return ((int[]) array).clone(); > } else if (array instanceof long[]) { > return ((long[]) array).clone(); > - } else if (array instanceof double[]) { > - return ((double[]) array).clone(); > + } else if (array instanceof short[]) { > + return ((short[]) array).clone(); > } else { > throw new AssertionError(); > } Ouch, I recall reviewing this code when it was added, but evidently missed this. FWIW, the change looks good to me [peterjones]. > You'll notice there is no regression test for this change. One justification is that the fix is in the "obviously no bugs" category. [1] There is an if-else instanceof chain over Object arrays and arrays of each primitive type; there are two checks for double and none for short so changing the one of the double checks to short is "obviously correct." Agreed. > Also, I've taken a stab a writing an explicit regression test for this condition, but the problem only manifests in cases beyond my direct serialization experience where a class has overridden the readUnshared method. I think that there was a test to go along with the bug fix that added this code (although evidently it didn't cover the short[] case). I don't see it in the hg repository now, I wonder if that's because the bug had the security keyword. Regards, -- Peter From joe.darcy at oracle.com Mon Dec 6 07:35:40 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 05 Dec 2010 23:35:40 -0800 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: References: <4CF91573.2070408@oracle.com> Message-ID: <4CFC924C.90607@oracle.com> Hi Peter. Peter Jones wrote: > Joe, > > On Dec 3, 2010, at 11:06 AM, Joe Darcy wrote: > >> Please review this simple fix for >> >> 6990094 "ObjectInputStream cloneArray doesn't handle short[]" >> http://cr.openjdk.java.net/~darcy/6990094.0/ >> >> The complete patch is >> >> --- old/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800 >> +++ new/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800 >> @@ -3498,8 +3498,8 @@ >> return ((int[]) array).clone(); >> } else if (array instanceof long[]) { >> return ((long[]) array).clone(); >> - } else if (array instanceof double[]) { >> - return ((double[]) array).clone(); >> + } else if (array instanceof short[]) { >> + return ((short[]) array).clone(); >> } else { >> throw new AssertionError(); >> } >> > > Ouch, I recall reviewing this code when it was added, but evidently missed this. FWIW, the change looks good to me [peterjones]. > > >> You'll notice there is no regression test for this change. One justification is that the fix is in the "obviously no bugs" category. [1] There is an if-else instanceof chain over Object arrays and arrays of each primitive type; there are two checks for double and none for short so changing the one of the double checks to short is "obviously correct." >> > > Agreed. > > >> Also, I've taken a stab a writing an explicit regression test for this condition, but the problem only manifests in cases beyond my direct serialization experience where a class has overridden the readUnshared method. >> > > I think that there was a test to go along with the bug fix that added this code (although evidently it didn't cover the short[] case). I don't see it in the hg repository now, I wonder if that's because the bug had the security keyword. > Off-list, Alan found the a related closed test and Stuart and I have developed an explicit test that tickles this bug: http://cr.openjdk.java.net/~darcy/6990094.1/ I plan to shortly push the fix with the test, although the test might be renamed or tweaked first, Thanks, -Joe From forax at univ-mlv.fr Mon Dec 6 08:10:23 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 06 Dec 2010 09:10:23 +0100 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: <4CFC924C.90607@oracle.com> References: <4CF91573.2070408@oracle.com> <4CFC924C.90607@oracle.com> Message-ID: <4CFC9A6F.7060100@univ-mlv.fr> Le 06/12/2010 08:35, Joe Darcy a ?crit : > Hi Peter. [...] > Off-list, Alan found the a related closed test and Stuart and I have > developed an explicit test that tickles this bug: > > http://cr.openjdk.java.net/~darcy/6990094.1/ > > I plan to shortly push the fix with the test, although the test might > be renamed or tweaked first, > > Thanks, > > -Joe Hi Joe, In the test, I don't see why the replacement field has to be static in Resolver. In my opinion, a private final field is sufficient. R?mi From maurizio.cimadamore at oracle.com Mon Dec 6 11:52:28 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 06 Dec 2010 11:52:28 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20101206115236.C6EAB4715F@hg.openjdk.java.net> Changeset: 5fb14e67c371 Author: mcimadamore Date: 2010-12-06 11:49 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5fb14e67c371 7003744: Compiler error concerning final variables Summary: Flow analysis does not cleanup init/uninint bit masks after for-loop Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/util/Bits.java + test/tools/javac/DefiniteAssignment/7003744/T7003744a.java + test/tools/javac/DefiniteAssignment/7003744/T7003744b.java Changeset: 56f59723fddf Author: mcimadamore Date: 2010-12-06 11:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/56f59723fddf 7002070: If catch clause has an incompatible type, error pointer points to first exception type in list Summary: Attribution should check each component of a disjunctive type separately, rather than checking the corresponding lub() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/multicatch/Neg06.java + test/tools/javac/multicatch/Neg06.out Changeset: 536ee9f126b1 Author: mcimadamore Date: 2010-12-06 11:51 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/536ee9f126b1 5088429: varargs overloading problem Summary: compiler implementation for overload resolution w/ varargs method does not match JLS Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/5088429/T5088429Neg01.java + test/tools/javac/varargs/5088429/T5088429Neg01.out + test/tools/javac/varargs/5088429/T5088429Neg02.java + test/tools/javac/varargs/5088429/T5088429Neg02.out + test/tools/javac/varargs/5088429/T5088429Pos01.java + test/tools/javac/varargs/5088429/T5088429Pos02.java From pcj at roundroom.net Mon Dec 6 16:03:24 2010 From: pcj at roundroom.net (Peter Jones) Date: Mon, 6 Dec 2010 11:03:24 -0500 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: <4CFC9A6F.7060100@univ-mlv.fr> References: <4CF91573.2070408@oracle.com> <4CFC924C.90607@oracle.com> <4CFC9A6F.7060100@univ-mlv.fr> Message-ID: On Mon, Dec 6, 2010 at 2:35 AM, Joe Darcy wrote: > Off-list, Alan found the a related closed test and Stuart and I have > developed an explicit test that tickles this bug: > > ? http://cr.openjdk.java.net/~darcy/6990094.1/ Looks good to me. On Mon, Dec 6, 2010 at 3:10 AM, R?mi Forax wrote: > Hi Joe, > In the test, I don't see why the replacement field has to be static in > Resolver. > In my opinion, a private final field is sufficient. I don't know on what instance you would set such an instance field, to control the exact reference returned by invoking readUnshared on a deserialized instance. The attack scenario addressed by the original bug fix would likely use a static field similarly. -- Peter From forax at univ-mlv.fr Mon Dec 6 17:15:39 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 06 Dec 2010 18:15:39 +0100 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: References: <4CF91573.2070408@oracle.com> <4CFC924C.90607@oracle.com> <4CFC9A6F.7060100@univ-mlv.fr> Message-ID: <4CFD1A3B.6050500@univ-mlv.fr> On 12/06/2010 05:03 PM, Peter Jones wrote: > On Mon, Dec 6, 2010 at 2:35 AM, Joe Darcy wrote: >> Off-list, Alan found the a related closed test and Stuart and I have >> developed an explicit test that tickles this bug: >> >> http://cr.openjdk.java.net/~darcy/6990094.1/ > Looks good to me. > > On Mon, Dec 6, 2010 at 3:10 AM, R?mi Forax wrote: >> Hi Joe, >> In the test, I don't see why the replacement field has to be static in >> Resolver. >> In my opinion, a private final field is sufficient. > I don't know on what instance you would set such an instance field, to > control the exact reference returned by invoking readUnshared on a > deserialized instance. The attack scenario addressed by the original > bug fix would likely use a static field similarly. > > -- Peter I mean create two instances sharing the same replacement Object. static class Resolver implements Serializable { private final Object replacement; public Resolver(Object o) { this.replacement = replacement; } private Object readResolve() throws ObjectStreamException { return replacement; } } private static void test(Object replacement) throws IOException, ClassNotFoundException { try(ByteArrayOutputStream baos = new ByteArrayOutputStream()) { try(ObjectOutputStream oos = new ObjectOutputStream(baos)) { oos.writeObject(new Resolver(replacement)); oos.writeObject(new Resolver(replacement)); } R?mi From vincent.x.ryan at oracle.com Mon Dec 6 18:56:02 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 06 Dec 2010 18:56:02 +0000 Subject: hg: jdk7/tl/jdk: 6557615: Method toString() of java.security.Timestamp throws IndexOutOfBoundsException if CertPath has empty Message-ID: <20101206185621.D191547171@hg.openjdk.java.net> Changeset: e7ab4e27f1e1 Author: vinnie Date: 2010-12-06 18:52 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7ab4e27f1e1 6557615: Method toString() of java.security.Timestamp throws IndexOutOfBoundsException if CertPath has empty Reviewed-by: mullan ! src/share/classes/java/security/Timestamp.java From mandy.chung at oracle.com Mon Dec 6 19:26:31 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 06 Dec 2010 11:26:31 -0800 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFA326C.1090500@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> Message-ID: <4CFD38E7.2020705@oracle.com> Remi, Eamonn, Brian, David, Doug, Thanks for the feedback. On 12/04/10 04:22, Eamonn McManus wrote: > Hi Mandy, > > This test: > > if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) == 1) { > > is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 > helpfully flags this; I'm not sure if earlier versions do.) > Good catch. This explains why the speed up for RUNNABLE was not as high in the microbenchmark measurement. Correcting it shows that Thread.getState() gets 3.5X speed up on a thread in RUNNABLE state. > But, once corrected, I think you could use this idea further to write > a much simpler and faster method, on these lines: > > public static Thread.State toThreadState(int threadStatus) { > if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE)*!= 0*) { > return RUNNABLE; > } else if ((threadStatus& JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { > return BLOCKED; > } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) != 0) { > return TIMED_WAITING; > } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_INDEFINITELY) != 0) { > return WAITING; > } else if ((threadStatus& JVMTI_THREAD_STATE_TERMINATED) != 0) { > return TERMINATED; > } else { > return NEW; > } > } I forgot to mention in the email that I implemented this simpler approach to compare with the table lookup approach. There were no significant difference. I now rerun with the corrected fix (checking != 0 rather than == 1) and the table lookup approach is about 2-6% faster than the sequence of tests approach. I am also for the simpler approach but I post the table lookup approach as a proposed fix to get any opinion on the performance aspect with that approach. Given that the Fork-Join framework doesn't depend on it, I will go for a simpler approach (sequence of tests) and further tune its performance when there is a use case requiring a perf improvement. New webrev: http://cr.openjdk.java.net/~mchung/6977034/webrev.01/ Can you review this version? Thanks Mandy > You could tweak the order of the tests based on what might be the > relative frequency of the different states but it probably isn't worth it. > > Regards, > ?amonn > > On 3/12/10 11:52 PM, Mandy Chung wrote: >> Fix for 6977034: Thread.getState() very slow >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >> >> This is an improvement to map a Thread's threadStatus field to >> Thread.State. The VM updates the Thread.threadStatus field directly >> at state transition with the value as defined in JVM TI [1]. The >> java.lang.Thread.getState() implementation can directly access the >> threadStatus value and do a direct lookup from an array of >> Thread.State. The threadStatus value is a bit vector and we would >> have to create an array of a minimum of 1061 (0x425) elements to do >> direct mapping. I took the approach to use the first highest order >> bit set to 1 in the masked threadStatus value as the index to the >> Thread.State element and only caches 32 elements (could be fewer). I >> wrote a micro-benchmark measuring the Thread.getState of a thread in >> different state that shows 1.7X to 6X speedup (see below). There is >> possibly some issue with my micro-benchmark that I didn't observe the >> 14X speed up as Doug did in his experiment. However, I'd like to get >> this reviewed and pushed to the repository so that anyone can do more >> experiment on the performance measurement. >> >> Thanks >> Mandy >> P.S. The discussion on this thread can be found at [2] [3]. >> >> [1] >> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >> [3] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >> >> >> JDK 7 b120 (in ms) With fix (in ms) Speed up >> main 46465 22772 2.04 >> NEW 50676 29921 1.69 >> RUNNABLE 42202 14690 2.87 >> BLOCKED 72773 12296 5.92 >> WAITING 48811 13041 3.74 >> TIMED_WAITING 45737 12849 3.56 >> TERMINATED 40314 16376 2.46 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xueming.shen at oracle.com Mon Dec 6 21:14:16 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 06 Dec 2010 21:14:16 +0000 Subject: hg: jdk7/tl/jdk: 6989148: (fs) zip provider should be available "out of the box" Message-ID: <20101206211426.8C1F447177@hg.openjdk.java.net> Changeset: 9758119b818c Author: sherman Date: 2010-12-06 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9758119b818c 6989148: (fs) zip provider should be available "out of the box" Summary: zip filesystem provider update, add zipfs.jar into ext dir Reviewed-by: alanb ! make/mkdemo/nio/zipfs/Makefile ! src/share/demo/nio/zipfs/Demo.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider ! src/share/demo/nio/zipfs/README.txt - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java + src/share/demo/nio/zipfs/src/META-INF/services/java.nio.file.spi.FileSystemProvider + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java + src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java + src/share/demo/zipfs ! test/demo/zipfs/Basic.java ! test/demo/zipfs/ZipFSTester.java From eamonn.mcmanus at oracle.com Mon Dec 6 22:41:23 2010 From: eamonn.mcmanus at oracle.com (Eamonn McManus) Date: Mon, 06 Dec 2010 23:41:23 +0100 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFD38E7.2020705@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFD38E7.2020705@oracle.com> Message-ID: <4CFD6693.6080600@oracle.com> An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Mon Dec 6 23:04:24 2010 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 06 Dec 2010 15:04:24 -0800 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: <4CFD1A3B.6050500@univ-mlv.fr> References: <4CF91573.2070408@oracle.com> <4CFC924C.90607@oracle.com> <4CFC9A6F.7060100@univ-mlv.fr> <4CFD1A3B.6050500@univ-mlv.fr> Message-ID: <4CFD6BF8.4010607@oracle.com> Hi R?mi, I think instead of public Resolver(Object o) { this.replacement = replacement; } that you meant public Resolver(Object o) { this.replacement = o; } Correct? Anyway, the technique you suggest does work to reproduce the bug, in that it causes Resolver.readResolve() to return a reference to the same object when it deserializes two different objects. The code does so by serializing the same object twice and pushing it through the object stream. However, this is a fairly roundabout way of causing the bug to occur. All that's necessary is to make sure that Resolver.readResolve() returns the same reference twice. The easiest way to do this is with a static. In fact, I've suggested to Joe that he remove the setReplacement() method and just assign to a static in the top-level class, just prior to the calls to readUnshared(). That makes it clear that there's nothing tricky going on in during serialization, just during deserialization. s'marks On 12/6/10 9:15 AM, R?mi Forax wrote: > On 12/06/2010 05:03 PM, Peter Jones wrote: >> On Mon, Dec 6, 2010 at 2:35 AM, Joe Darcy wrote: >>> Off-list, Alan found the a related closed test and Stuart and I have >>> developed an explicit test that tickles this bug: >>> >>> http://cr.openjdk.java.net/~darcy/6990094.1/ >> Looks good to me. >> >> On Mon, Dec 6, 2010 at 3:10 AM, R?mi Forax wrote: >>> Hi Joe, >>> In the test, I don't see why the replacement field has to be static in >>> Resolver. >>> In my opinion, a private final field is sufficient. >> I don't know on what instance you would set such an instance field, to >> control the exact reference returned by invoking readUnshared on a >> deserialized instance. The attack scenario addressed by the original >> bug fix would likely use a static field similarly. >> >> -- Peter > > I mean create two instances sharing the same replacement Object. > > static class Resolver implements Serializable { > private final Object replacement; > > public Resolver(Object o) { > this.replacement = replacement; > } > private Object readResolve() throws ObjectStreamException { > return replacement; > } > } > > private static void test(Object replacement) > throws IOException, ClassNotFoundException { > > try(ByteArrayOutputStream baos = new ByteArrayOutputStream()) { > try(ObjectOutputStream oos = new ObjectOutputStream(baos)) { > oos.writeObject(new Resolver(replacement)); > oos.writeObject(new Resolver(replacement)); > } > > R?mi From mandy.chung at oracle.com Mon Dec 6 23:35:31 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 06 Dec 2010 15:35:31 -0800 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFD6693.6080600@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFD38E7.2020705@oracle.com> <4CFD6693.6080600@oracle.com> Message-ID: <4CFD7343.3070901@oracle.com> On 12/6/10 2:41 PM, Eamonn McManus wrote: > Reviewed OK! > The constant JVMTI_THREAD_STATE_WAITING is not used but that's my only > minor niggle. Will take it out. Thanks for the review. Mandy > ?amonn [emcmanus] > > On 06/12/2010 20:26, Mandy Chung wrote: >> Remi, Eamonn, Brian, David, Doug, >> >> Thanks for the feedback. >> >> On 12/04/10 04:22, Eamonn McManus wrote: >>> Hi Mandy, >>> >>> This test: >>> >>> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) == 1) { >>> >>> is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans >>> 7.0 helpfully flags this; I'm not sure if earlier versions do.) >>> >> >> Good catch. This explains why the speed up for RUNNABLE was not as >> high in the microbenchmark measurement. Correcting it shows that >> Thread.getState() gets 3.5X speed up on a thread in RUNNABLE state. >> >>> But, once corrected, I think you could use this idea further to >>> write a much simpler and faster method, on these lines: >>> >>> public static Thread.State toThreadState(int threadStatus) { >>> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE)*!= 0*) { >>> return RUNNABLE; >>> } else if ((threadStatus& JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { >>> return BLOCKED; >>> } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) != 0) { >>> return TIMED_WAITING; >>> } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_INDEFINITELY) != 0) { >>> return WAITING; >>> } else if ((threadStatus& JVMTI_THREAD_STATE_TERMINATED) != 0) { >>> return TERMINATED; >>> } else { >>> return NEW; >>> } >>> } >> >> I forgot to mention in the email that I implemented this simpler >> approach to compare with the table lookup approach. There were no >> significant difference. I now rerun with the corrected fix (checking >> != 0 rather than == 1) and the table lookup approach is about 2-6% >> faster than the sequence of tests approach. >> >> I am also for the simpler approach but I post the table lookup >> approach as a proposed fix to get any opinion on the performance >> aspect with that approach. >> >> Given that the Fork-Join framework doesn't depend on it, I will go >> for a simpler approach (sequence of tests) and further tune its >> performance when there is a use case requiring a perf improvement. >> >> New webrev: >> http://cr.openjdk.java.net/~mchung/6977034/webrev.01/ >> >> Can you review this version? >> >> Thanks >> Mandy >> >>> You could tweak the order of the tests based on what might be the >>> relative frequency of the different states but it probably isn't >>> worth it. >>> >>> Regards, >>> ?amonn >>> >>> On 3/12/10 11:52 PM, Mandy Chung wrote: >>>> Fix for 6977034: Thread.getState() very slow >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >>>> >>>> This is an improvement to map a Thread's threadStatus field to >>>> Thread.State. The VM updates the Thread.threadStatus field >>>> directly at state transition with the value as defined in JVM TI >>>> [1]. The java.lang.Thread.getState() implementation can directly >>>> access the threadStatus value and do a direct lookup from an array >>>> of Thread.State. The threadStatus value is a bit vector and we >>>> would have to create an array of a minimum of 1061 (0x425) elements >>>> to do direct mapping. I took the approach to use the first >>>> highest order bit set to 1 in the masked threadStatus value as the >>>> index to the Thread.State element and only caches 32 elements >>>> (could be fewer). I wrote a micro-benchmark measuring the >>>> Thread.getState of a thread in different state that shows 1.7X to >>>> 6X speedup (see below). There is possibly some issue with my >>>> micro-benchmark that I didn't observe the 14X speed up as Doug did >>>> in his experiment. However, I'd like to get this reviewed and >>>> pushed to the repository so that anyone can do more experiment on >>>> the performance measurement. >>>> >>>> Thanks >>>> Mandy >>>> P.S. The discussion on this thread can be found at [2] [3]. >>>> >>>> [1] >>>> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >>>> [3] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >>>> >>>> >>>> JDK 7 b120 (in ms) With fix (in ms) Speed up >>>> main 46465 22772 2.04 >>>> NEW 50676 29921 1.69 >>>> RUNNABLE 42202 14690 2.87 >>>> BLOCKED 72773 12296 5.92 >>>> WAITING 48811 13041 3.74 >>>> TIMED_WAITING 45737 12849 3.56 >>>> TERMINATED 40314 16376 2.46 >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Holmes at oracle.com Mon Dec 6 23:56:06 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 07 Dec 2010 09:56:06 +1000 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFD38E7.2020705@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFD38E7.2020705@oracle.com> Message-ID: <4CFD7816.9040309@oracle.com> Thumbs up from me. Thanks, David Mandy Chung said the following on 12/07/10 05:26: > Remi, Eamonn, Brian, David, Doug, > > Thanks for the feedback. > > On 12/04/10 04:22, Eamonn McManus wrote: >> Hi Mandy, >> >> This test: >> >> if ((threadStatus & JVMTI_THREAD_STATE_RUNNABLE) == 1) { >> >> is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 >> helpfully flags this; I'm not sure if earlier versions do.) >> > > Good catch. This explains why the speed up for RUNNABLE was not as > high in the microbenchmark measurement. Correcting it shows that > Thread.getState() gets 3.5X speed up on a thread in RUNNABLE state. > >> But, once corrected, I think you could use this idea further to write >> a much simpler and faster method, on these lines: >> >> public static Thread.State toThreadState(int threadStatus) { >> if ((threadStatus & JVMTI_THREAD_STATE_RUNNABLE) *!= 0*) { >> return RUNNABLE; >> } else if ((threadStatus & JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { >> return BLOCKED; >> } else if ((threadStatus & JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) != 0) { >> return TIMED_WAITING; >> } else if ((threadStatus & JVMTI_THREAD_STATE_WAITING_INDEFINITELY) != 0) { >> return WAITING; >> } else if ((threadStatus & JVMTI_THREAD_STATE_TERMINATED) != 0) { >> return TERMINATED; >> } else { >> return NEW; >> } >> } > > I forgot to mention in the email that I implemented this simpler > approach to compare with the table lookup approach. There were no > significant difference. I now rerun with the corrected fix (checking != > 0 rather than == 1) and the table lookup approach is about 2-6% faster > than the sequence of tests approach. > > I am also for the simpler approach but I post the table lookup approach > as a proposed fix to get any opinion on the performance aspect with that > approach. > > Given that the Fork-Join framework doesn't depend on it, I will go for a > simpler approach (sequence of tests) and further tune its performance > when there is a use case requiring a perf improvement. > > New webrev: > http://cr.openjdk.java.net/~mchung/6977034/webrev.01/ > > Can you review this version? > > Thanks > Mandy > >> You could tweak the order of the tests based on what might be the >> relative frequency of the different states but it probably isn't worth it. >> >> Regards, >> ?amonn >> >> On 3/12/10 11:52 PM, Mandy Chung wrote: >>> Fix for 6977034: Thread.getState() very slow >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >>> >>> This is an improvement to map a Thread's threadStatus field to >>> Thread.State. The VM updates the Thread.threadStatus field directly >>> at state transition with the value as defined in JVM TI [1]. The >>> java.lang.Thread.getState() implementation can directly access the >>> threadStatus value and do a direct lookup from an array of >>> Thread.State. The threadStatus value is a bit vector and we would >>> have to create an array of a minimum of 1061 (0x425) elements to do >>> direct mapping. I took the approach to use the first highest order >>> bit set to 1 in the masked threadStatus value as the index to the >>> Thread.State element and only caches 32 elements (could be fewer). I >>> wrote a micro-benchmark measuring the Thread.getState of a thread in >>> different state that shows 1.7X to 6X speedup (see below). There is >>> possibly some issue with my micro-benchmark that I didn't observe the >>> 14X speed up as Doug did in his experiment. However, I'd like to get >>> this reviewed and pushed to the repository so that anyone can do more >>> experiment on the performance measurement. >>> >>> Thanks >>> Mandy >>> P.S. The discussion on this thread can be found at [2] [3]. >>> >>> [1] >>> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >>> [2] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >>> [3] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >>> >>> >>> JDK 7 b120 (in ms) With fix (in ms) Speed up >>> main 46465 22772 2.04 >>> NEW 50676 29921 1.69 >>> RUNNABLE 42202 14690 2.87 >>> BLOCKED 72773 12296 5.92 >>> WAITING 48811 13041 3.74 >>> TIMED_WAITING 45737 12849 3.56 >>> TERMINATED 40314 16376 2.46 >>> > From rob.lougher at gmail.com Tue Dec 7 01:27:35 2010 From: rob.lougher at gmail.com (Robert Lougher) Date: Tue, 7 Dec 2010 01:27:35 +0000 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: <4CFD38E7.2020705@oracle.com> References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFD38E7.2020705@oracle.com> Message-ID: Hi Mandy, On 6 December 2010 19:26, Mandy Chung wrote: > Remi, Eamonn, Brian, David, Doug, > > Thanks for the feedback. > I don't know if you welcome external feedback, but I'd like to point out (if you're not already aware) that this change modifies the VM interface. While I'm cognisant of the reason for the change, my understanding of the existing map mechanism is that it makes the JDK class library independent of the underlying VM thread status values. The value of Thread.threadStatus is opaque, with the mapping from VM thread status being determined by the following VM interface functions (see hotspot/src/share/vm/prims/jvm.h): ------------------ /* * Returns an array of the threadStatus values representing the * given Java thread state. Returns NULL if the VM version is * incompatible with the JDK or doesn't support the given * Java thread state. */ JNIEXPORT jintArray JNICALL JVM_GetThreadStateValues(JNIEnv* env, jint javaThreadState); /* * Returns an array of the substate names representing the * given Java thread state. Returns NULL if the VM version is * incompatible with the JDK or the VM doesn't support * the given Java thread state. * values must be the jintArray returned from JVM_GetThreadStateValues * and javaThreadState. */ JNIEXPORT jobjectArray JNICALL JVM_GetThreadStateNames(JNIEnv* env, jint javaThreadState, jintArray values); ------------------ These two functions are used by the native method sun.misc.VM.getThreadStateValues to setup the arrays which are then used to initialise the map. This change breaks this abstraction, and requires Thread.threadStatus to be a JVM TI thread state (which happens to match Hotspot's internal thread state). This change will therefore break any VM which does not have an internal thread state based on JVM TI. As far as I'm aware, IKVM and CACAO are currently the only other users of OpenJDK (I'm also nearing completion of a port to JamVM). Unfortunately, from looking at CACAO I can see that this change will break it. It may also break IKVM, but I haven't checked. I, of course, can modify the internal thread states of JamVM to be compatible. I'm CC'ing CACAO's mailing list and GNU Classpath so that affected parties can be made aware of this change. As an aside, will there be any later clean-up of the native method implementation and VM interface? Thanks, Rob. > On 12/04/10 04:22, Eamonn McManus wrote: > > Hi Mandy, > > This test: > > if ((threadStatus & JVMTI_THREAD_STATE_RUNNABLE) == 1) { > > is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 > helpfully flags this; I'm not sure if earlier versions do.) > > Good catch.?? This explains why the speed up for RUNNABLE was not as high in > the microbenchmark measurement.? Correcting it shows that Thread.getState() > gets 3.5X speed up on a thread in RUNNABLE state. > > But, once corrected, I think you could use this idea further to write a much > simpler and faster method, on these lines: > > public static Thread.State toThreadState(int threadStatus) { > if ((threadStatus & JVMTI_THREAD_STATE_RUNNABLE) != 0) { > return RUNNABLE; > } else if ((threadStatus & > JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { > return BLOCKED; > } else if ((threadStatus & JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) > != 0) { > return TIMED_WAITING; > } else if ((threadStatus & JVMTI_THREAD_STATE_WAITING_INDEFINITELY) > != 0) { > return WAITING; > } else if ((threadStatus & JVMTI_THREAD_STATE_TERMINATED) != 0) { > return TERMINATED; > } else { > return NEW; > } > } > > I forgot to mention in the email that I implemented this simpler approach to > compare with the table lookup approach.?? There were no significant > difference.? I now rerun with the corrected fix (checking != 0 rather than > == 1) and the table lookup approach is about 2-6% faster than the sequence > of tests approach. > > I am also for the simpler approach but I post the table lookup approach as a > proposed fix to get any opinion on the performance aspect with that > approach. > > Given that the Fork-Join framework doesn't depend on it, I will go for a > simpler approach (sequence of tests) and further tune its performance when > there is a use case requiring a perf improvement. > > New webrev: > ?? http://cr.openjdk.java.net/~mchung/6977034/webrev.01/ > > Can you review this version? > > Thanks > Mandy > > You could tweak the order of the tests based on what might be the relative > frequency of the different states but it probably isn't worth it. > > Regards, > > ?amonn > > On 3/12/10 11:52 PM, Mandy Chung wrote: > > Fix for 6977034: Thread.getState() very slow > > Webrev at: > ?? http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ > > This is an improvement to map a Thread's threadStatus field to > Thread.State.? The VM updates the Thread.threadStatus field directly at > state transition with the value as defined in JVM TI [1].? The > java.lang.Thread.getState() implementation can directly access the > threadStatus value and do a direct lookup from an array of Thread.State. > The threadStatus value is a bit vector and we would have to create an array > of a minimum of 1061 (0x425) elements to do direct mapping.?? I took the > approach to use the first highest order bit set to 1 in the masked > threadStatus value as the index to the Thread.State element and only caches > 32 elements (could be fewer).? I wrote a micro-benchmark measuring the > Thread.getState of a thread in different state that shows 1.7X to 6X speedup > (see below).? There is possibly some issue with my micro-benchmark that I > didn't observe the 14X speed up as Doug did in his experiment.? However, I'd > like to get this reviewed and pushed to the repository so that anyone can do > more experiment on the performance measurement. > > Thanks > Mandy > P.S. The discussion on this thread can be found at [2] [3]. > > [1] > http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html > > > JDK 7 b120 (in ms) With fix (in ms) Speed up > main 46465 22772 2.04 > NEW 50676 29921 1.69 > RUNNABLE 42202 14690 2.87 > BLOCKED 72773 12296 5.92 > WAITING 48811 13041 3.74 > TIMED_WAITING 45737 12849 3.56 > TERMINATED 40314 16376 2.46 > > > From weijun.wang at oracle.com Tue Dec 7 01:53:05 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 07 Dec 2010 01:53:05 +0000 Subject: hg: jdk7/tl/jdk: 6986825: policytool can not save file. Message-ID: <20101207015315.8EDAC47183@hg.openjdk.java.net> Changeset: 34f8b6669273 Author: weijun Date: 2010-12-07 09:51 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/34f8b6669273 6986825: policytool can not save file. Reviewed-by: wetmore ! src/share/classes/sun/security/tools/policytool/PolicyTool.java From mandy.chung at oracle.com Tue Dec 7 02:22:26 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 06 Dec 2010 18:22:26 -0800 Subject: Review request for 6977034 Thread.getState() very slow In-Reply-To: References: <4CF974BC.2030503@oracle.com> <4CFA326C.1090500@oracle.com> <4CFD38E7.2020705@oracle.com> Message-ID: <4CFD9A62.1050209@oracle.com> On 12/6/10 5:27 PM, Robert Lougher wrote: > Hi Mandy, > > On 6 December 2010 19:26, Mandy Chung wrote: >> Remi, Eamonn, Brian, David, Doug, >> >> Thanks for the feedback. >> > I don't know if you welcome external feedback, but I'd like to point > out (if you're not already aware) that this change modifies the VM > interface. Any feedback is welcome. That's the intent to post this for the openjdk discussion. Thanks for the information that this change will break CACAO of OpenJDK. > While I'm cognisant of the reason for the change, my understanding of > the existing map mechanism is that it makes the JDK class library > independent of the underlying VM thread status values. The value of > Thread.threadStatus is opaque, with the mapping from VM thread status > being determined by the following VM interface functions (see > hotspot/src/share/vm/prims/jvm.h): > > ------------------ > /* > * Returns an array of the threadStatus values representing the > * given Java thread state. Returns NULL if the VM version is > * incompatible with the JDK or doesn't support the given > * Java thread state. > */ > JNIEXPORT jintArray JNICALL > JVM_GetThreadStateValues(JNIEnv* env, jint javaThreadState); > > /* > * Returns an array of the substate names representing the > * given Java thread state. Returns NULL if the VM version is > * incompatible with the JDK or the VM doesn't support > * the given Java thread state. > * values must be the jintArray returned from JVM_GetThreadStateValues > * and javaThreadState. > */ > JNIEXPORT jobjectArray JNICALL > JVM_GetThreadStateNames(JNIEnv* env, jint javaThreadState, jintArray values); > > ------------------ > > These two functions are used by the native method > sun.misc.VM.getThreadStateValues to setup the arrays which are then > used to initialise the map. > > This change breaks this abstraction, and requires Thread.threadStatus > to be a JVM TI thread state (which happens to match Hotspot's internal > thread state). This change will therefore break any VM which does not > have an internal thread state based on JVM TI. > Indeed this fix will depend on this private interface between VM and JDK to set the threadStatus as JVM TI thread state. The VM implementation of setting Thread.threadStatus hasn't been changed since 1.5 and performance required by the profiling tools was one of the reasons done in that way. > As far as I'm aware, IKVM and CACAO are currently the only other users > of OpenJDK (I'm also nearing completion of a port to JamVM). > Unfortunately, from looking at CACAO I can see that this change will > break it. It may also break IKVM, but I haven't checked. I, of > course, can modify the internal thread states of JamVM to be > compatible. > > I'm CC'ing CACAO's mailing list and GNU Classpath so that affected > parties can be made aware of this change. Thanks for doing that. > As an aside, will there be > any later clean-up of the native method implementation and VM > interface? I don't know of the project status. I suggest you to post this question to the common VM interface openjdk project: http://openjdk.java.net/projects/cvmi/ cvmi-dev at openjdk.java.net Thanks Mandy > Thanks, > Rob. > >> On 12/04/10 04:22, Eamonn McManus wrote: >> >> Hi Mandy, >> >> This test: >> >> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) == 1) { >> >> is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0 >> helpfully flags this; I'm not sure if earlier versions do.) >> >> Good catch. This explains why the speed up for RUNNABLE was not as high in >> the microbenchmark measurement. Correcting it shows that Thread.getState() >> gets 3.5X speed up on a thread in RUNNABLE state. >> >> But, once corrected, I think you could use this idea further to write a much >> simpler and faster method, on these lines: >> >> public static Thread.State toThreadState(int threadStatus) { >> if ((threadStatus& JVMTI_THREAD_STATE_RUNNABLE) != 0) { >> return RUNNABLE; >> } else if ((threadStatus& >> JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) { >> return BLOCKED; >> } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT) >> != 0) { >> return TIMED_WAITING; >> } else if ((threadStatus& JVMTI_THREAD_STATE_WAITING_INDEFINITELY) >> != 0) { >> return WAITING; >> } else if ((threadStatus& JVMTI_THREAD_STATE_TERMINATED) != 0) { >> return TERMINATED; >> } else { >> return NEW; >> } >> } >> >> I forgot to mention in the email that I implemented this simpler approach to >> compare with the table lookup approach. There were no significant >> difference. I now rerun with the corrected fix (checking != 0 rather than >> == 1) and the table lookup approach is about 2-6% faster than the sequence >> of tests approach. >> >> I am also for the simpler approach but I post the table lookup approach as a >> proposed fix to get any opinion on the performance aspect with that >> approach. >> >> Given that the Fork-Join framework doesn't depend on it, I will go for a >> simpler approach (sequence of tests) and further tune its performance when >> there is a use case requiring a perf improvement. >> >> New webrev: >> http://cr.openjdk.java.net/~mchung/6977034/webrev.01/ >> >> Can you review this version? >> >> Thanks >> Mandy >> >> You could tweak the order of the tests based on what might be the relative >> frequency of the different states but it probably isn't worth it. >> >> Regards, >> >> ?amonn >> >> On 3/12/10 11:52 PM, Mandy Chung wrote: >> >> Fix for 6977034: Thread.getState() very slow >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/6977034/webrev.00/ >> >> This is an improvement to map a Thread's threadStatus field to >> Thread.State. The VM updates the Thread.threadStatus field directly at >> state transition with the value as defined in JVM TI [1]. The >> java.lang.Thread.getState() implementation can directly access the >> threadStatus value and do a direct lookup from an array of Thread.State. >> The threadStatus value is a bit vector and we would have to create an array >> of a minimum of 1061 (0x425) elements to do direct mapping. I took the >> approach to use the first highest order bit set to 1 in the masked >> threadStatus value as the index to the Thread.State element and only caches >> 32 elements (could be fewer). I wrote a micro-benchmark measuring the >> Thread.getState of a thread in different state that shows 1.7X to 6X speedup >> (see below). There is possibly some issue with my micro-benchmark that I >> didn't observe the 14X speed up as Doug did in his experiment. However, I'd >> like to get this reviewed and pushed to the repository so that anyone can do >> more experiment on the performance measurement. >> >> Thanks >> Mandy >> P.S. The discussion on this thread can be found at [2] [3]. >> >> [1] >> http://download.java.net/jdk7/docs/platform/jvmti/jvmti.html#GetThreadState >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-July/004567.html >> [3] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004721.html >> >> >> JDK 7 b120 (in ms) With fix (in ms) Speed up >> main 46465 22772 2.04 >> NEW 50676 29921 1.69 >> RUNNABLE 42202 14690 2.87 >> BLOCKED 72773 12296 5.92 >> WAITING 48811 13041 3.74 >> TIMED_WAITING 45737 12849 3.56 >> TERMINATED 40314 16376 2.46 >> >> >> From mike.duigou at oracle.com Tue Dec 7 03:44:09 2010 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 07 Dec 2010 03:44:09 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101207034427.BC18247188@hg.openjdk.java.net> Changeset: 964eae6d1cab Author: mduigou Date: 2010-12-06 19:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/964eae6d1cab 7004205: fixes handling of sane-gcc-compiler on 32-bit linux and solaris. Previously committed as 6998016 and 6998012 Reviewed-by: ohair, dholmes ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: e97a9a2892e2 Author: mduigou Date: 2010-12-06 19:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e97a9a2892e2 Merge From joe.darcy at oracle.com Tue Dec 7 09:10:52 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 07 Dec 2010 09:10:52 +0000 Subject: hg: jdk7/tl/jdk: 6990094: ObjectInputStream cloneArray doesn't handle short[] Message-ID: <20101207091102.1E88847195@hg.openjdk.java.net> Changeset: 733ef59db5a9 Author: darcy Date: 2010-12-07 01:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/733ef59db5a9 6990094: ObjectInputStream cloneArray doesn't handle short[] Reviewed-by: alanb, smarks, peterjones ! src/share/classes/java/io/ObjectInputStream.java + test/java/io/Serializable/cloneArray/CloneArray.java From weijun.wang at oracle.com Tue Dec 7 09:32:55 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 07 Dec 2010 09:32:55 +0000 Subject: hg: jdk7/tl/jdk: 6990370: FindBugs scan - Malicious code vulnerability Warnings in com.sun.jndi.ldap.* Message-ID: <20101207093305.1593947197@hg.openjdk.java.net> Changeset: beeea65e79f4 Author: weijun Date: 2010-12-07 17:30 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/beeea65e79f4 6990370: FindBugs scan - Malicious code vulnerability Warnings in com.sun.jndi.ldap.* Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/BasicControl.java From Ulf.Zibis at gmx.de Tue Dec 7 11:55:12 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 07 Dec 2010 12:55:12 +0100 Subject: Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]" In-Reply-To: <4CF91573.2070408@oracle.com> References: <4CF91573.2070408@oracle.com> Message-ID: <4CFE20A0.5060303@gmx.de> Am 03.12.2010 17:06, schrieb Joe Darcy: > > [1] "There are two ways of constructing a software design. One way is to make it so simple that > there are obviously no deficiencies. And the other way is to make it so complicated that there are > no obvious deficiencies." C.A.R. Hoare] > I think, the reason for this bug is the unconventional order of the items in the if...else... sequence. Why don't you order it like? : Object boolean byte char short int long float double (hopefully we soon have switch...case on instanceof and objects!) -Ulf From michael.x.mcmahon at oracle.com Tue Dec 7 13:30:41 2010 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 07 Dec 2010 13:30:41 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101207133108.126C0471A0@hg.openjdk.java.net> Changeset: aeaadac45240 Author: michaelm Date: 2010-12-07 13:27 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aeaadac45240 7005016: sqe test jhttp/HttpServer150013/HttpServer150013.java Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerConfig.java + test/com/sun/net/httpserver/Test10.java Changeset: 9e173410b4d5 Author: michaelm Date: 2010-12-07 13:29 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9e173410b4d5 Merge - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java From jonathan.gibbons at oracle.com Tue Dec 7 22:13:56 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 07 Dec 2010 22:13:56 +0000 Subject: hg: jdk7/tl/langtools: 6999210: javac should be able to warn of anomalous conditions in classfiles Message-ID: <20101207221358.CE208471BC@hg.openjdk.java.net> Changeset: 3c32c90031fd Author: jjg Date: 2010-12-07 14:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3c32c90031fd 6999210: javac should be able to warn of anomalous conditions in classfiles Reviewed-by: mcimadamore, darcy ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/T6999210.java ! test/tools/javac/annotations/6214965/T6214965.out ! test/tools/javac/annotations/6365854/test1.out ! test/tools/javac/annotations/6365854/test2.out ! test/tools/javac/diags/examples.not-yet.txt From xueming.shen at oracle.com Tue Dec 7 23:53:47 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 07 Dec 2010 15:53:47 -0800 Subject: Code review request for 6415373 Message-ID: <4CFEC90B.9040203@oracle.com> Please help review the change for 6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode http://cr.openjdk.java.net/~sherman/6415373/webrev Thanks, -Sherman From sean.mullan at oracle.com Wed Dec 8 18:29:31 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 08 Dec 2010 18:29:31 +0000 Subject: hg: jdk7/tl/jdk: 6998860: Signed jar file verification is currently creating many extra new Sun providers. Message-ID: <20101208182940.A81F2471FA@hg.openjdk.java.net> Changeset: 291128e77395 Author: mullan Date: 2010-12-08 10:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/291128e77395 6998860: Signed jar file verification is currently creating many extra new Sun providers. Reviewed-by: mchung ! src/share/classes/sun/security/util/ManifestEntryVerifier.java From mandy.chung at oracle.com Wed Dec 8 18:58:27 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 08 Dec 2010 18:58:27 +0000 Subject: hg: jdk7/tl/jdk: 6977034: Thread.getState() very slow Message-ID: <20101208185837.641F6471FC@hg.openjdk.java.net> Changeset: acce526a49a7 Author: mchung Date: 2010-12-08 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/acce526a49a7 6977034: Thread.getState() very slow Summary: Directly map the threadStatus value to Thread.State Reviewed-by: emcmanus, dholmes ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/VM.java From xueming.shen at oracle.com Wed Dec 8 20:12:12 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 08 Dec 2010 20:12:12 +0000 Subject: hg: jdk7/tl/jdk: 6527572: (cs) Charset.forName can throw NullPointerException when testing bug level Message-ID: <20101208201221.BF25A47200@hg.openjdk.java.net> Changeset: 01b6d147db50 Author: sherman Date: 2010-12-08 12:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/01b6d147db50 6527572: (cs) Charset.forName can throw NullPointerException when testing bug level Summary: fixed the race condition Reviewed-by: alanb ! src/share/classes/java/nio/charset/Charset.java From Alan.Bateman at oracle.com Wed Dec 8 20:33:15 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Dec 2010 20:33:15 +0000 Subject: Code review request for 6415373 In-Reply-To: <4CFEC90B.9040203@oracle.com> References: <4CFEC90B.9040203@oracle.com> Message-ID: <4CFFEB8B.3040702@oracle.com> Xueming Shen wrote: > > Please help review the change for > 6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode > > http://cr.openjdk.java.net/~sherman/6415373/webrev > > Thanks, > > -Sherman The fix looks okay to me, and the updated test case looks much better. -Alan. From xueming.shen at oracle.com Wed Dec 8 20:51:19 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 08 Dec 2010 20:51:19 +0000 Subject: hg: jdk7/tl/jdk: 6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode Message-ID: <20101208205128.DB5AB47202@hg.openjdk.java.net> Changeset: 956de70712e0 Author: sherman Date: 2010-12-08 12:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/956de70712e0 6415373: (cs) UnicodeEncoder emits BOM when there are no bytes to encode Summary: no BOM output if no byte to encode Reviewed-by: alanb ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java + test/sun/nio/cs/EncodingNothing.java From jonathan.gibbons at oracle.com Wed Dec 8 21:43:20 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 08 Dec 2010 21:43:20 +0000 Subject: hg: jdk7/tl/langtools: 7004698: javap does not output CharacterRangeTable attributes correctly Message-ID: <20101208214322.BC40947205@hg.openjdk.java.net> Changeset: acb02e1d5119 Author: jjg Date: 2010-12-08 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/acb02e1d5119 7004698: javap does not output CharacterRangeTable attributes correctly Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javap/T7004698.java From abhi.saha at oracle.com Wed Dec 8 23:47:21 2010 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Wed, 08 Dec 2010 23:47:21 +0000 Subject: hg: jdk7/tl/corba: 6877056: SVUID calculated for java.lang.Enum is not 0L Message-ID: <20101208234722.9A1B247216@hg.openjdk.java.net> Changeset: 5d9708346d50 Author: miroslawzn Date: 2010-12-08 10:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/5d9708346d50 6877056: SVUID calculated for java.lang.Enum is not 0L Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java From bluedavy at gmail.com Mon Dec 6 05:30:37 2010 From: bluedavy at gmail.com (BlueDavy Lin) Date: Mon, 6 Dec 2010 13:30:37 +0800 Subject: An advice: Can List/Set/Map support limited size? Message-ID: hi! In our applications,many oom cases are caused by auto expand List/Set/Map/StringBuilder,so if JDK API can add limited size api,I think it'll be helpful,such as: new ArrayList(initialCapacity,maxCapacity). :) Such as in google collections,MapMaker.maximumSize(1000) can do this. Expected your reply. -- ============================= |? ?? BlueDavy? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | |? ?? OSGi China User Group Director? ? | |? ?? http://china.osgiusers.org? ? ? ? ? ? ?? | |? ?? http://www.bluedavy.com? ?? | ============================= From jaroslav.tulach at oracle.com Wed Dec 8 23:03:39 2010 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 9 Dec 2010 00:03:39 +0100 Subject: StringBuffer.build() - a way to create strings without unnecessary allocations Message-ID: <201012090003.39607.jaroslav.tulach@oracle.com> Hello. Can anybody hear me? I'd like to talk to someone who cares about String, StringBuffer and StringBuilder. I am NetBeans Platform architect and I'd like to use this opportunity to fasten start of NetBeans as well as improve OpenJDK project. Here is my story: I've been investigating the memory allocations during NetBeans start. I've noticed that we are allocating about 60MB of char[] mostly due to parsing of various configuration files. Suprisingly at least half of these 60MB is garbage collected quickly. This is because we use StringBuffer/Builder to concatenate the texts and then convert them to String. The conversion to String however allocates new array. I believe this is less then optimal. However there is no way I can tell the Java libraries to be more effective. That is why I decided to create my patch. It adds StringBuffer.build() method which can create Strings without unnecessary copying. It adds StringBuilder.build() method too, for symetry, but that one is not that effective (I don't know how to make it robust without usage of synchronization). If I had StringBuffer.build, I could allocate only 30MB of data on NetBeans startup and very likely make it faster. Can you consider adding this method to JDK7? I am attaching my patch that adds the new API. I can refine it, add new tests, etc. I just need a buddy interested in StringBuffer to guide me. I belive that together we can make NetBeans start faster and OpenJDK7 better. Can you help me? -jt -------------- next part -------------- A non-text attachment was scrubbed... Name: StringBuffer.build.diff Type: text/x-patch Size: 3032 bytes Desc: not available URL: From forax at univ-mlv.fr Thu Dec 9 00:17:16 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 09 Dec 2010 01:17:16 +0100 Subject: StringBuffer.build() - a way to create strings without unnecessary allocations In-Reply-To: <201012090003.39607.jaroslav.tulach@oracle.com> References: <201012090003.39607.jaroslav.tulach@oracle.com> Message-ID: <4D00200C.8070505@univ-mlv.fr> I will answer with a question. Correct me if i'm wrong. You see no slowdown to use StringBuffers instead of StringBuilders. This means that perhaps the VM is able to remove synchronization block. Which means that the NetBeans startup is most done by one thread. If you want to improve the startup time, why not doing this initialization in parallel. R?mi On 12/09/2010 12:03 AM, Jaroslav Tulach wrote: > Hello. > Can anybody hear me? I'd like to talk to someone who cares about String, > StringBuffer and StringBuilder. I am NetBeans Platform architect and I'd like > to use this opportunity to fasten start of NetBeans as well as improve OpenJDK > project. Here is my story: > > I've been investigating the memory allocations during NetBeans start. I've > noticed that we are allocating about 60MB of char[] mostly due to parsing of > various configuration files. Suprisingly at least half of these 60MB is > garbage collected quickly. This is because we use StringBuffer/Builder to > concatenate the texts and then convert them to String. The conversion to > String however allocates new array. I believe this is less then optimal. > However there is no way I can tell the Java libraries to be more effective. > > That is why I decided to create my patch. It adds StringBuffer.build() method > which can create Strings without unnecessary copying. It adds > StringBuilder.build() method too, for symetry, but that one is not that > effective (I don't know how to make it robust without usage of > synchronization). If I had StringBuffer.build, I could allocate only 30MB of > data on NetBeans startup and very likely make it faster. Can you consider > adding this method to JDK7? > > I am attaching my patch that adds the new API. I can refine it, add new tests, > etc. I just need a buddy interested in StringBuffer to guide me. I belive that > together we can make NetBeans start faster and OpenJDK7 better. Can you help > me? > > -jt From tom.hawtin at oracle.com Thu Dec 9 01:54:51 2010 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Thu, 09 Dec 2010 01:54:51 +0000 Subject: StringBuffer.build() - a way to create strings without unnecessary allocations In-Reply-To: <201012090003.39607.jaroslav.tulach@oracle.com> References: <201012090003.39607.jaroslav.tulach@oracle.com> Message-ID: <4D0036EB.806@oracle.com> On 08/12/2010 23:03, Jaroslav Tulach wrote: > I've been investigating the memory allocations during NetBeans start. I've > noticed that we are allocating about 60MB of char[] mostly due to parsing of > various configuration files. Suprisingly at least half of these 60MB is > garbage collected quickly. This is because we use StringBuffer/Builder to You should find that short-lived memory allocations are very well handled. If half the memory allocations are going to be long-lived, then the short-lived allocations should be relatively insignificant. > That is why I decided to create my patch. It adds StringBuffer.build() method > which can create Strings without unnecessary copying. It adds This is how StringBuffer was implemented before 1.5. It turns out that this is not technically thread-safe for StringBuffer, and StringBuilder would obviously allow mutable Strings. Also there is the problem that the StringBuffer char[] will typically be longer than necessary, so pruning is generally a good idea. You might find that you can reduce memory churn by retaining the same StringBuffer object, removing the contents between uses. But this is likely to make a mess of your code, and is unlikely to give much actual performance improvement. Tom From xueming.shen at oracle.com Thu Dec 9 04:09:53 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 09 Dec 2010 04:09:53 +0000 Subject: hg: jdk7/tl/jdk: 5076980: (fmt) FormattableFlags specifies unsupported '^' format flag Message-ID: <20101209041002.885E047220@hg.openjdk.java.net> Changeset: 03513756704c Author: sherman Date: 2010-12-08 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/03513756704c 5076980: (fmt) FormattableFlags specifies unsupported '^' format flag Summary: replaced '^' with 'S' in spec Reviewed-by: darcy ! src/share/classes/java/util/FormattableFlags.java From joe.darcy at oracle.com Thu Dec 9 04:57:59 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 Dec 2010 20:57:59 -0800 Subject: hg: jdk7/tl/jdk: 6991528: Support making Throwable.suppressedExceptions immutable In-Reply-To: <4CE03788.6040109@univ-mlv.fr> References: <20101114152348.F28BA479C6@hg.openjdk.java.net> <4CE03788.6040109@univ-mlv.fr> Message-ID: <4D0061D7.1050400@oracle.com> R?mi Forax wrote: > Le 14/11/2010 16:23, joe.darcy at oracle.com a ?crit : >> Changeset: e1a1a2f5d7e1 >> Author: darcy >> Date: 2010-11-14 07:22 -0800 >> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a1a2f5d7e1 >> >> 6991528: Support making Throwable.suppressedExceptions immutable >> Reviewed-by: mchung, dholmes >> >> ! src/share/classes/java/lang/StackTraceElement.java >> ! src/share/classes/java/lang/Throwable.java >> ! test/java/lang/Throwable/StackTraceSerialization.java >> ! test/java/lang/Throwable/SuppressedExceptions.java >> >> > > Hi Joe, > StackTraceElement.equals checks if methodName is null > even if it can not be null by construction. > Also the code can be a little more efficient > if the lineNumber are checked before checking the declaring class. > > The code should be: > > return e.lineNumber == lineNumber && > e.declaringClass.equals(declaringClass) && > methodName.equals(e.methodName) && > Objects.equals(fileName, e.fileName); > > R?mi Hi R?mi. I'll consider making those changes when I go back to make the Throwable.stackTrace field immutable (6998871). Thanks, -Joe From joe.darcy at oracle.com Thu Dec 9 05:17:58 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 09 Dec 2010 05:17:58 +0000 Subject: hg: jdk7/tl/langtools: 7003550: Loosen modeling requirements for annotation processing erroneous code Message-ID: <20101209051800.14F8947225@hg.openjdk.java.net> Changeset: 23fc45d3a572 Author: darcy Date: 2010-12-08 21:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/23fc45d3a572 7003550: Loosen modeling requirements for annotation processing erroneous code Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/package-info.java From forax at univ-mlv.fr Thu Dec 9 09:37:05 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 09 Dec 2010 10:37:05 +0100 Subject: hg: jdk7/tl/jdk: 6991528: Support making Throwable.suppressedExceptions immutable In-Reply-To: <4D0061D7.1050400@oracle.com> References: <20101114152348.F28BA479C6@hg.openjdk.java.net> <4CE03788.6040109@univ-mlv.fr> <4D0061D7.1050400@oracle.com> Message-ID: <4D00A341.4070800@univ-mlv.fr> Le 09/12/2010 05:57, Joe Darcy a ?crit : > R?mi Forax wrote: >> Le 14/11/2010 16:23, joe.darcy at oracle.com a ?crit : >>> Changeset: e1a1a2f5d7e1 >>> Author: darcy >>> Date: 2010-11-14 07:22 -0800 >>> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a1a2f5d7e1 >>> >>> 6991528: Support making Throwable.suppressedExceptions immutable >>> Reviewed-by: mchung, dholmes >>> >>> ! src/share/classes/java/lang/StackTraceElement.java >>> ! src/share/classes/java/lang/Throwable.java >>> ! test/java/lang/Throwable/StackTraceSerialization.java >>> ! test/java/lang/Throwable/SuppressedExceptions.java >>> >> >> Hi Joe, >> StackTraceElement.equals checks if methodName is null >> even if it can not be null by construction. >> Also the code can be a little more efficient >> if the lineNumber are checked before checking the declaring class. >> >> The code should be: >> >> return e.lineNumber == lineNumber && >> e.declaringClass.equals(declaringClass) && >> methodName.equals(e.methodName) && >> Objects.equals(fileName, e.fileName); >> >> R?mi > > Hi R?mi. > > I'll consider making those changes when I go back to make the > Throwable.stackTrace field immutable (6998871). > > Thanks, > > -Joe Hi Joe, Thanks for tracking this. In my opinion you should also get ride of PrintStreamOrWriter by using an Appendable or by introducing a common interface for PrintWriter and PrintStream declaring print/println. R?mi From forax at univ-mlv.fr Thu Dec 9 09:48:29 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 09 Dec 2010 10:48:29 +0100 Subject: hg: jdk7/tl/jdk: 6991528: Support making Throwable.suppressedExceptions immutable In-Reply-To: <4D0061D7.1050400@oracle.com> References: <20101114152348.F28BA479C6@hg.openjdk.java.net> <4CE03788.6040109@univ-mlv.fr> <4D0061D7.1050400@oracle.com> Message-ID: <4D00A5ED.8000604@univ-mlv.fr> Le 09/12/2010 05:57, Joe Darcy a ?crit : > R?mi Forax wrote: >> Le 14/11/2010 16:23, joe.darcy at oracle.com a ?crit : >>> Changeset: e1a1a2f5d7e1 >>> Author: darcy >>> Date: 2010-11-14 07:22 -0800 >>> URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1a1a2f5d7e1 >>> >>> 6991528: Support making Throwable.suppressedExceptions immutable >>> Reviewed-by: mchung, dholmes >>> >>> ! src/share/classes/java/lang/StackTraceElement.java >>> ! src/share/classes/java/lang/Throwable.java >>> ! test/java/lang/Throwable/StackTraceSerialization.java >>> ! test/java/lang/Throwable/SuppressedExceptions.java >>> >> >> Hi Joe, >> StackTraceElement.equals checks if methodName is null >> even if it can not be null by construction. >> Also the code can be a little more efficient >> if the lineNumber are checked before checking the declaring class. >> >> The code should be: >> >> return e.lineNumber == lineNumber && >> e.declaringClass.equals(declaringClass) && >> methodName.equals(e.methodName) && >> Objects.equals(fileName, e.fileName); >> >> R?mi > > Hi R?mi. > > I'll consider making those changes when I go back to make the > Throwable.stackTrace field immutable (6998871). > > Thanks, > > -Joe In fact you can't use Appendable because there is no way to set the error flag of a PrintStream or a PrintWriter if the append method throws an IOException. R?mi From maurizio.cimadamore at oracle.com Thu Dec 9 15:52:35 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 09 Dec 2010 15:52:35 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20101209155241.2A1994723D@hg.openjdk.java.net> Changeset: 5ef88773462b Author: mcimadamore Date: 2010-12-09 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5ef88773462b 7005095: Cast: compile reject sensible cast from final class to interface Summary: a previous fix to cast conversion has made the compiler too strict w.r.t. final cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7005095/T7005095neg.java + test/tools/javac/cast/7005095/T7005095neg.out + test/tools/javac/cast/7005095/T7005095pos.java Changeset: 1d625fbe6c22 Author: mcimadamore Date: 2010-12-09 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1d625fbe6c22 6476118: compiler bug causes runtime ClassCastException for generics overloading Summary: compiler allows bridge methods to override unrelated method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6476118/T6476118a.java + test/tools/javac/generics/6476118/T6476118a.out + test/tools/javac/generics/6476118/T6476118b.java + test/tools/javac/generics/6476118/T6476118b.out + test/tools/javac/generics/6476118/T6476118c.java + test/tools/javac/generics/6476118/T6476118c.out + test/tools/javac/generics/6476118/T6476118d.java Changeset: e3df8d7a9752 Author: mcimadamore Date: 2010-12-09 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e3df8d7a9752 7005371: Multicatch: assertion error while generating LocalVariableTypeTable attribute Summary: compiler crashes with assertion error if '-g' option is passed and source contains multicatch Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/multicatch/7005371/SubTest.java + test/tools/javac/multicatch/7005371/T7005371.java From jonathan.gibbons at oracle.com Thu Dec 9 16:25:39 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 09 Dec 2010 16:25:39 +0000 Subject: hg: jdk7/tl/langtools: 4917091: javac rejects array over 128 in length Message-ID: <20101209162541.E14B14723F@hg.openjdk.java.net> Changeset: bcf44475aeee Author: jjg Date: 2010-12-09 08:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bcf44475aeee 4917091: javac rejects array over 128 in length Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/4917091/Test255.java + test/tools/javac/4917091/Test256a.java + test/tools/javac/4917091/Test256a.out + test/tools/javac/4917091/Test256b.java + test/tools/javac/4917091/Test256b.out From jonathan.gibbons at oracle.com Thu Dec 9 16:48:37 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 09 Dec 2010 16:48:37 +0000 Subject: hg: jdk7/tl/langtools: 6985202: no access to doc comments from Tree API Message-ID: <20101209164839.9D4AF47240@hg.openjdk.java.net> Changeset: 90914ac50868 Author: jjg Date: 2010-12-09 08:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/90914ac50868 6985202: no access to doc comments from Tree API Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/api/TestDocComments.java From lance.andersen at oracle.com Thu Dec 9 18:01:57 2010 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 09 Dec 2010 18:01:57 +0000 Subject: hg: jdk7/tl/jdk: 6659234: Incorrect check in SerialBlob.getBytes Message-ID: <20101209180219.DD0FA47245@hg.openjdk.java.net> Changeset: 1bf378034d39 Author: lancea Date: 2010-12-09 13:01 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bf378034d39 6659234: Incorrect check in SerialBlob.getBytes Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java From jonathan.gibbons at oracle.com Fri Dec 10 02:34:37 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 10 Dec 2010 02:34:37 +0000 Subject: hg: jdk7/tl/langtools: 7005856: avoid name clash for langtools when building on MacOS Message-ID: <20101210023439.336F94725B@hg.openjdk.java.net> Changeset: 4dd1c0176d81 Author: jjg Date: 2010-12-09 18:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4dd1c0176d81 7005856: avoid name clash for langtools when building on MacOS Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java From jonathan.gibbons at oracle.com Fri Dec 10 03:53:35 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 10 Dec 2010 03:53:35 +0000 Subject: hg: jdk7/tl/langtools: 6986242: cut-n-paste error in javadoc for Trees.instance(ProcessingEnvironment) Message-ID: <20101210035339.770E04725F@hg.openjdk.java.net> Changeset: 65820d0d4a97 Author: jjg Date: 2010-12-09 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/65820d0d4a97 6986242: cut-n-paste error in javadoc for Trees.instance(ProcessingEnvironment) Reviewed-by: darcy ! src/share/classes/com/sun/source/util/Trees.java From abhi.saha at oracle.com Fri Dec 10 05:13:06 2010 From: abhi.saha at oracle.com (abhi.saha at oracle.com) Date: Fri, 10 Dec 2010 05:13:06 +0000 Subject: hg: jdk7/tl/corba: 7004713: regression: cannot find symbol: variable delegate failed compile _Stub Message-ID: <20101210051308.16A0047263@hg.openjdk.java.net> Changeset: 33ca1bceec2d Author: skoppar Date: 2010-12-05 22:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/33ca1bceec2d 7004713: regression: cannot find symbol: variable delegate failed compile _Stub Summary: Also reviewed by ken.cavanaugh at oracle.com Reviewed-by: asaha ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/Stub.java From chris.hegarty at oracle.com Fri Dec 10 10:49:24 2010 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 10 Dec 2010 10:49:24 +0000 Subject: hg: jdk7/tl/jdk: 7004439: SCTP_SET_PEER_PRIMARY_ADDR throws SocketException on Linux Message-ID: <20101210104951.AC0994728E@hg.openjdk.java.net> Changeset: 79947a4ad7a1 Author: chegar Date: 2010-12-10 10:47 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79947a4ad7a1 7004439: SCTP_SET_PEER_PRIMARY_ADDR throws SocketException on Linux Summary: IPv4 addrs passed to SCTP_SET_PEER_PRIMARY_ADDR should not be converted to IPv4-mapped addrs Reviewed-by: michaelm ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/native/sun/nio/ch/SctpNet.c ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java From sean.coffey at oracle.com Fri Dec 10 15:10:21 2010 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 10 Dec 2010 15:10:21 +0000 Subject: hg: jdk7/tl/jdk: 6998583: NativeSeedGenerator is making 8192 byte read requests from entropy pool on each init. Message-ID: <20101210151039.AB48A47299@hg.openjdk.java.net> Changeset: 43ae1a1cc7a4 Author: coffeys Date: 2010-12-10 15:11 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/43ae1a1cc7a4 6998583: NativeSeedGenerator is making 8192 byte read requests from entropy pool on each init. Reviewed-by: wetmore, andrew, vinnie ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/windows/classes/sun/security/provider/NativeSeedGenerator.java + test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java From maurizio.cimadamore at oracle.com Fri Dec 10 15:25:37 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 10 Dec 2010 15:25:37 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101210152540.D6ABA4729A@hg.openjdk.java.net> Changeset: 2ca5866a8dfb Author: mcimadamore Date: 2010-12-10 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2ca5866a8dfb 7005671: Regression: compiler accepts invalid cast from X[] to primitive array Summary: regression in type conversion after 292 changes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7005671/T7005671.java + test/tools/javac/cast/7005671/T7005671.out Changeset: b1c98bfd4709 Author: mcimadamore Date: 2010-12-10 15:24 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b1c98bfd4709 6199075: Unambiguous varargs method calls flagged as ambiguous Summary: javac does not implement overload resolution w.r.t. varargs methods as described in the JLS Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/varargs/6199075/T6199075.java From jonathan.gibbons at oracle.com Fri Dec 10 15:46:53 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 10 Dec 2010 15:46:53 +0000 Subject: hg: jdk7/tl/langtools: 6504896: TreeMaker.Literal(Object) does not support Booleans Message-ID: <20101210154655.AD0974729C@hg.openjdk.java.net> Changeset: 8ec3a824f925 Author: jjg Date: 2010-12-10 07:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8ec3a824f925 6504896: TreeMaker.Literal(Object) does not support Booleans Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/tree/MakeLiteralTest.java From assembling.signals at yandex.ru Sun Dec 12 14:54:55 2010 From: assembling.signals at yandex.ru (assembling signals) Date: Sun, 12 Dec 2010 15:54:55 +0100 Subject: Source snapshot release - country-specific restriction? Message-ID: <896301292165695@web158.yandex.ru> Hello, community! Since JDK b121 I can't download JDK sources from here [ http://download.java.net/jdk7/ ], because my country (Germany) is not in some International Use Restrictions Due to limited intellectual property protection and enforcement in certain countries, the JDK source code may only be distributed to an authorized list of countries. You will not be able to access the source code if you are downloading from a country that is not on this list. We are continuously reviewing this list for addition of other countries. From assembling.signals at yandex.ru Sun Dec 12 14:57:49 2010 From: assembling.signals at yandex.ru (assembling signals) Date: Sun, 12 Dec 2010 15:57:49 +0100 Subject: Source snapshot release - country-specific restriction? [2] Message-ID: <587061292165869@web117.yandex.ru> Sorry, previous mail was sent too early ;) Once again: Hello, community! Since JDK b121 I can't download JDK sources from here [ http://download.java.net/jdk7/ ], because my country (Germany) is not in some green list for it. When I could expect to be able to download sources AGAIN? Is there still the possibility to get a hg-clone in such a way that I could use the checked-out sources for an IDE (mine is Netbeans) as JDK sources path? Thank you in advance. > International Use Restrictions > Due to limited intellectual property protection and enforcement in certain countries, the JDK source code may only be distributed to an authorized list of countries. You will not be able to access the source code if you are downloading from a country that is not on this list. We are continuously reviewing this list for addition of other countries. From jonathan.gibbons at oracle.com Sun Dec 12 18:06:07 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sun, 12 Dec 2010 18:06:07 +0000 Subject: hg: jdk7/tl/langtools: 6990134: minor (but red) findbugs warnings Message-ID: <20101212180609.B39D74731D@hg.openjdk.java.net> Changeset: 878c8f760ded Author: jjg Date: 2010-12-12 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/878c8f760ded 6990134: minor (but red) findbugs warnings Reviewed-by: mcimadamore + src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java From dalibor.topic at oracle.com Sun Dec 12 19:30:59 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sun, 12 Dec 2010 20:30:59 +0100 Subject: Source snapshot release - country-specific restriction? [2] In-Reply-To: <587061292165869@web117.yandex.ru> References: <587061292165869@web117.yandex.ru> Message-ID: <4D0522F3.40308@oracle.com> On 12/12/10 3:57 PM, assembling signals wrote: > Sorry, previous mail was sent too early ;) Once again: > > > Hello, community! > > Since JDK b121 I can't download JDK sources from here [ http://download.java.net/jdk7/ ], > because my country (Germany) is not in some green list for it. Works for me from Germany. Try http://download.java.net/openjdk/jdk7/ for the OpenJDK sources. > Is there still the possibility to get a hg-clone in such a way that I could use the checked-out sources for an IDE (mine is Netbeans) as JDK sources path? I'm not sure what that means. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From tom.hawtin at oracle.com Sun Dec 12 22:12:42 2010 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Sun, 12 Dec 2010 22:12:42 +0000 Subject: Source snapshot release - country-specific restriction? [2] In-Reply-To: <4D0522F3.40308@oracle.com> References: <587061292165869@web117.yandex.ru> <4D0522F3.40308@oracle.com> Message-ID: <4D0548DA.6030201@oracle.com> On 12/12/2010 19:30, Dalibor Topic wrote: > On 12/12/10 3:57 PM, assembling signals wrote: >> Since JDK b121 I can't download JDK sources from here [ http://download.java.net/jdk7/ ], >> because my country (Germany) is not in some green list for it. I assume this is related to the retirement of the JRL. http://robilad.livejournal.com/75483.html > Works for me from Germany. Try http://download.java.net/openjdk/jdk7/ for the OpenJDK sources. Yes, although if you are interested in the still-closed part of the JDK, such as the PlugIn, then it's tough. Tom From assembling.signals at yandex.ru Mon Dec 13 00:28:12 2010 From: assembling.signals at yandex.ru (assembling signals) Date: Mon, 13 Dec 2010 01:28:12 +0100 Subject: Source snapshot release - country-specific restriction? [2] Message-ID: <62211292200092@web77.yandex.ru> Thank you, the specified path works, and OpenJDK sources are for me as good as JDK sources. No, fortunately, no interest in the plugin. > I assume this is related to the retirement of the JRL. > http://robilad.livejournal.com/75483.html > > Yes, although if you are interested in the still-closed part of the JDK, > such as the PlugIn, then it's tough. > > Tom From lana.steuck at oracle.com Mon Dec 13 06:58:17 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 06:58:17 +0000 Subject: hg: jdk7/tl: 7 new changesets Message-ID: <20101213065817.55F3947340@hg.openjdk.java.net> Changeset: b011f9ab61f8 Author: paulk Date: 2010-11-17 11:55 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/b011f9ab61f8 6997515: KERNEL=0 in JDK7 build causes loss of lzma compression. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: ba8ec3e1e7f2 Author: jqzuo Date: 2010-12-07 19:18 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/ba8ec3e1e7f2 Merge Changeset: fe71f5684c6a Author: igor Date: 2010-11-16 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/fe71f5684c6a Merge Changeset: 7bf38037c3c9 Author: jqzuo Date: 2010-11-17 09:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/7bf38037c3c9 Merge Changeset: 05fbe45da7f7 Author: igor Date: 2010-11-30 09:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/05fbe45da7f7 Merge Changeset: 2c2d4f88637b Author: igor Date: 2010-12-07 16:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2c2d4f88637b Merge Changeset: f1591eed71f6 Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f1591eed71f6 Added tag jdk7-b121 for changeset 2c2d4f88637b ! .hgtags From lana.steuck at oracle.com Mon Dec 13 06:58:31 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 06:58:31 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b121 for changeset 3f3653ab7af8 Message-ID: <20101213065833.8269047341@hg.openjdk.java.net> Changeset: 3a548dc9cb45 Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3a548dc9cb45 Added tag jdk7-b121 for changeset 3f3653ab7af8 ! .hgtags From lana.steuck at oracle.com Mon Dec 13 06:59:11 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 06:59:11 +0000 Subject: hg: jdk7/tl/jaxp: 4 new changesets Message-ID: <20101213065912.0133C47342@hg.openjdk.java.net> Changeset: 1830ef24edb2 Author: lana Date: 2010-11-30 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/1830ef24edb2 Merge Changeset: 63dae40fa19f Author: lana Date: 2010-12-06 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/63dae40fa19f Merge Changeset: 03ff13d19c8f Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/03ff13d19c8f Added tag jdk7-b121 for changeset 63dae40fa19f ! .hgtags Changeset: 74d9007e9a6e Author: lana Date: 2010-12-12 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/74d9007e9a6e Merge From lana.steuck at oracle.com Mon Dec 13 06:59:17 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 06:59:17 +0000 Subject: hg: jdk7/tl/jaxws: 4 new changesets Message-ID: <20101213065917.2EAF047343@hg.openjdk.java.net> Changeset: ca2fa57106b3 Author: lana Date: 2010-11-30 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ca2fa57106b3 Merge Changeset: 0fa950117faa Author: lana Date: 2010-12-06 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/0fa950117faa Merge Changeset: 17b6c48a3449 Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/17b6c48a3449 Added tag jdk7-b121 for changeset 0fa950117faa ! .hgtags Changeset: ab1046d981c6 Author: lana Date: 2010-12-12 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ab1046d981c6 Merge From lana.steuck at oracle.com Mon Dec 13 07:01:41 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 07:01:41 +0000 Subject: hg: jdk7/tl/jdk: 43 new changesets Message-ID: <20101213070841.7807647344@hg.openjdk.java.net> Changeset: 23a6ba383fd7 Author: jgodinez Date: 2010-11-18 14:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23a6ba383fd7 6689925: Add transform attributes to the rendering tests in J2DBench Reviewed-by: flar, prr ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java Changeset: f81c37805b5b Author: lana Date: 2010-11-30 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f81c37805b5b Merge Changeset: 07c1c59df4ef Author: dav Date: 2010-11-18 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07c1c59df4ef 6990904: (dav) on oel5.5, Frame doesn't show if the Frame has only a MenuBar as its component. Reviewed-by: dcherepanov, art ! src/solaris/classes/sun/awt/X11/XFramePeer.java + test/java/awt/MenuBar/DeadlockTest1/DeadlockTest1.java Changeset: 9af8c8d2b2e7 Author: art Date: 2010-11-25 13:23 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9af8c8d2b2e7 6993784: Clarification to shaped/translucent windows specification is required Reviewed-by: anthony, dcherepanov ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/Window.java Changeset: dd603732f1cf Author: dav Date: 2010-11-25 15:39 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd603732f1cf 6551412: [OpenJDK] Change the 'name=' entry in src/windows/resource/java.manifest XML file. Reviewed-by: ohair ! src/windows/resource/java.manifest Changeset: 6c4e7fe53c36 Author: dcherepanov Date: 2010-11-26 11:27 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c4e7fe53c36 6561353: The text for J2SE NervousText demo should be updated to 7.0 Reviewed-by: art ! src/share/demo/applets/NervousText/example1.html Changeset: b6d79a32b07a Author: dcherepanov Date: 2010-11-26 14:36 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b6d79a32b07a 6699851: setMaximizedbounds not working properly on dual screen environment Reviewed-by: art, anthony ! src/share/classes/java/awt/Frame.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WFramePeer.java Changeset: 3a2355dcef13 Author: dcherepanov Date: 2010-11-26 15:07 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a2355dcef13 6770017: PIT : java/awt/Choice/BlockedWin32Choice/BlockedWin32Choice.java fails on 6u12 b01 pit build Reviewed-by: art ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h Changeset: 31196f8ec2d9 Author: anthony Date: 2010-11-26 15:41 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31196f8ec2d9 7002856: Provide an accessor for Container.validateUnconditionally() Summary: Introduce sun.awt.AWTAccessor.getContainerAccessor().validateUnconditionally() Reviewed-by: art ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java Changeset: 7ed7eb6d6ba7 Author: dcherepanov Date: 2010-11-26 15:52 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7ed7eb6d6ba7 6953894: docs build reports warning in java.awt.FileDialog Reviewed-by: art ! src/share/classes/java/awt/FileDialog.java Changeset: 4becb3dd7861 Author: anthony Date: 2010-11-30 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4becb3dd7861 6998592: FileDialog tests crashed on solaris Summary: Override GtkFileDialogPeer.toFront() Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.h Changeset: 357ecafd727b Author: dav Date: 2010-11-30 21:54 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/357ecafd727b 6783910: (dav) java.awt.Color.brighter()/darker() methods make color opaque Reviewed-by: art, yan ! src/share/classes/java/awt/Color.java + test/java/awt/Color/OpacityChange/OpacityChange.java Changeset: 5fc778c913e7 Author: lana Date: 2010-11-30 14:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5fc778c913e7 Merge Changeset: 452c4c1cc747 Author: vikram Date: 2010-11-15 21:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/452c4c1cc747 6939261: Since 1.6.0_18 JMenus at JMenuBar are not selectable by their Mnemonic key anymore Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java Changeset: 3207aa4438fc Author: peytoia Date: 2010-11-17 01:02 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3207aa4438fc 6959267: Support Unicode 6.0.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData00.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/Scripts.txt ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt ! make/tools/UnicodeData/VERSION ! src/share/classes/java/awt/font/NumericShaper.java ! src/share/classes/java/lang/Character.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.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/awt/font/NumericShaper/ShapingTest.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/Scripts.txt Changeset: a1c87d76d322 Author: naoto Date: 2010-11-16 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a1c87d76d322 6997999: Remove duplicated entries from ISO language/country code tables Reviewed-by: okutsu ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/lang/locale_str.h ! test/java/util/Locale/data/deflocale.rhel5 ! test/java/util/Locale/data/deflocale.rhel5.fmtasdefault Changeset: e6932dbf30d8 Author: malenkov Date: 2010-11-17 22:17 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6932dbf30d8 6447751: Bean Customizer should be detectable by reflection name alone Reviewed-by: peterz ! src/share/classes/java/beans/Introspector.java + test/java/beans/Introspector/Test6447751.java Changeset: 4222206d85e8 Author: alexp Date: 2010-11-18 13:53 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4222206d85e8 6994419: JLayer.removeAll() behavior doesn't correspond to JLayer.remove() behavior. Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6994419/bug6994419.java Changeset: 10965b60a13e Author: alexp Date: 2010-11-18 19:52 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10965b60a13e 6997170: Spec for javax.swing.plaf.LayerUI.installUI/uninstallUI() methods contradict behavior of the RI Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/LayerUI.java Changeset: ef4db681a1fd Author: naoto Date: 2010-11-18 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef4db681a1fd 7000136: Backward compatibility problem in LocaleNameProvider Reviewed-by: srl Contributed-by: y.umaoka at gmail.com ! src/share/classes/java/util/spi/LocaleNameProvider.java Changeset: 917aca396b10 Author: naoto Date: 2010-11-23 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/917aca396b10 6930106: Testcases with legal notice problems Reviewed-by: ohair ! test/java/util/ResourceBundle/Bug4168625Test.java Changeset: 13bbabfee6d4 Author: peytoia Date: 2010-11-24 14:13 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/13bbabfee6d4 7002398: Apply Corrigendum #8 for Unicode 6.0.0 Reviewed-by: okutsu ! make/tools/UnicodeData/UnicodeData.txt ! src/share/classes/sun/text/resources/ubidi.icu ! src/share/classes/sun/text/resources/uprops.icu + test/java/text/Bidi/Bug7002398.java Changeset: f5708f506523 Author: naoto Date: 2010-11-24 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f5708f506523 6807534: CurrencyNameProvider.getDisplayName(String, Locale) doesn't throw IllegalArgumentException Reviewed-by: okutsu ! src/share/classes/java/util/spi/CurrencyNameProvider.java + test/java/util/Currency/Bug6807534.java Changeset: 9461aeec7d9c Author: amenkov Date: 2010-11-25 15:58 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9461aeec7d9c 6999872: java.awt.Window instantiation leads to JVM CRASH on Windows, JDK7b118+ fastdebug Reviewed-by: igor, dcherepanov ! src/windows/bin/java_md.c ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 5ae935cdc84d Author: alexp Date: 2010-11-25 20:23 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5ae935cdc84d 6992847: javax/swing/JLayer/SerializationTest/SerializationTest.java failed in jdk7 just against b114 Reviewed-by: rupashka ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java Changeset: 98318c740242 Author: alexp Date: 2010-11-25 20:25 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98318c740242 7002176: JLayer docs build produces warnings Reviewed-by: dav ! src/share/classes/javax/swing/JLayer.java Changeset: 3104dfd74072 Author: alexp Date: 2010-11-29 16:01 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3104dfd74072 6559589: Memory leak in JScrollPane.updateUI() Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java + test/javax/swing/JScrollPane/6559589/bug6559589.java Changeset: 54fc4039ddc8 Author: alexp Date: 2010-11-29 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54fc4039ddc8 6939001: Nimbus: JTabbedPane setBackgroundAt and setForegroundAt have no effect Reviewed-by: rupashka ! src/share/classes/javax/swing/JTabbedPane.java Changeset: 562d25d284e9 Author: alexp Date: 2010-11-29 16:11 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/562d25d284e9 6939227: Nimbus: 6597895 for JCheckBox, JButton and JToggleButton JCK tests Reviewed-by: rupashka ! src/share/classes/javax/swing/AbstractButton.java Changeset: 602dfe45c227 Author: malenkov Date: 2010-11-29 20:38 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/602dfe45c227 6999033: Methods BorderFactory.createSoftBevelBorder() don't return SoftBevelBorder instances Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java Changeset: 3d92a0fbf5cb Author: malenkov Date: 2010-11-29 21:20 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3d92a0fbf5cb 6981576: TitledBorder.getBorder() returns null in java build 1.7.0-ea-b107 Reviewed-by: alexp ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test6981576.java Changeset: 7890dd8535f8 Author: lana Date: 2010-11-29 10:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7890dd8535f8 Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: d9e3d4f54bad Author: rupashka Date: 2010-11-30 10:35 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d9e3d4f54bad 6988188: The test failed due to Applet thread threw exception Reviewed-by: alexp + test/javax/swing/JFileChooser/4150029/bug4150029.html + test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: 88308d3affa0 Author: lana Date: 2010-11-30 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/88308d3affa0 Merge Changeset: b868e7e73a25 Author: lana Date: 2010-11-30 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b868e7e73a25 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: c65ab22137f8 Author: lana Date: 2010-12-06 20:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c65ab22137f8 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 720863527b90 Author: herrick Date: 2010-10-22 14:14 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/720863527b90 Merge Changeset: 1a6bcdf42058 Author: igor Date: 2010-11-18 10:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1a6bcdf42058 Merge - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java Changeset: f32734df1bdd Author: ccheung Date: 2010-11-09 23:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f32734df1bdd 6992226: Missing windows COMPANY file property settings Reviewed-by: ohair ! make/common/Defs.gmk Changeset: 4f33cfb40c39 Author: igor Date: 2010-11-30 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f33cfb40c39 Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: a661d8587b5d Author: igor Date: 2010-12-08 00:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a661d8587b5d Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: ac311eb325bf Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ac311eb325bf Added tag jdk7-b121 for changeset a661d8587b5d ! .hgtags Changeset: 4a18d1bb21c3 Author: lana Date: 2010-12-12 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a18d1bb21c3 Merge From lana.steuck at oracle.com Mon Dec 13 07:10:33 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 07:10:33 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20101213071040.ACEA247346@hg.openjdk.java.net> Changeset: 1bf969e9792f Author: lana Date: 2010-12-06 20:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1bf969e9792f Merge - test/tools/javac/diags/examples/EmptyBytecodeIdent.java - test/tools/javac/diags/examples/IllegalBytecodeIdentChar.java - test/tools/javac/diags/examples/UnclosedBytecodeIdent.java - test/tools/javac/diags/examples/UnsupportedExoticID.java - test/tools/javac/quid/QuotedIdent.java - test/tools/javac/quid/QuotedIdent2.java Changeset: 11e7b4c0476e Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/11e7b4c0476e Added tag jdk7-b121 for changeset 1bf969e9792f ! .hgtags Changeset: fe43a7efd273 Author: lana Date: 2010-12-12 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fe43a7efd273 Merge Changeset: dd9b5f767559 Author: lana Date: 2010-12-12 21:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd9b5f767559 Merge - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java From lana.steuck at oracle.com Mon Dec 13 06:52:48 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 13 Dec 2010 06:52:48 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20101213065249.5DACA4733E@hg.openjdk.java.net> Changeset: 1523a060032c Author: katleman Date: 2010-12-09 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/1523a060032c Added tag jdk7-b121 for changeset 2cc9f3299210 ! .hgtags Changeset: 18e9f50c8d13 Author: lana Date: 2010-12-12 10:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/18e9f50c8d13 Merge From maurizio.cimadamore at oracle.com Mon Dec 13 14:58:04 2010 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 13 Dec 2010 14:58:04 +0000 Subject: hg: jdk7/tl/langtools: 7006109: Add test library to simplify the task of writing automated type-system tests Message-ID: <20101213145808.542F747358@hg.openjdk.java.net> Changeset: 2199365892b1 Author: mcimadamore Date: 2010-12-13 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2199365892b1 7006109: Add test library to simplify the task of writing automated type-system tests Summary: Types.java needs to be more stress-tested Reviewed-by: jjg + test/tools/javac/types/BoxingConversionTest.java + test/tools/javac/types/CastTest.java + test/tools/javac/types/PrimitiveConversionTest.java + test/tools/javac/types/TypeHarness.java From vincent.x.ryan at oracle.com Mon Dec 13 15:08:35 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 13 Dec 2010 15:08:35 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101213150854.CF48F47359@hg.openjdk.java.net> Changeset: 8f0957d16c20 Author: vinnie Date: 2010-12-13 14:58 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8f0957d16c20 6799854: CodeSigner.hashCode() does not work with serialization Reviewed-by: mullan ! src/share/classes/java/security/CodeSigner.java ! src/share/classes/java/security/Timestamp.java ! src/share/native/sun/security/ec/ECC_JNI.cpp + test/java/security/CodeSigner/Serialize.java + test/java/security/CodeSigner/cert_file Changeset: 2d858fb6110d Author: vinnie Date: 2010-12-13 15:07 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2d858fb6110d Merge - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java From neil.richards at ngmr.net Mon Dec 13 17:59:57 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 13 Dec 2010 17:59:57 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock Message-ID: Hello. I have a fix and testcase for problem 6934356 in the Java bug database - "Vector.writeObject() synchronization risks serialization deadlock". I've included the 'hg diff -g' output below. I'm new to OpenJDK - though not to Java SE implementation development - so hope that this is correct mailing list to ask for the code to be reviewed. (Please point me towards a better list if this is not so). Also, given that this is a reported bug in the Java bug database, I'm a little confused as to whether I need to additionally raise it in https://bugs.openjdk.java.net/ And, indeed, whether it is better for me to include the 'hg diff -g' output inline, as I have done below, or as an attachment, or in some other fashion. Basically, any guidance will be gratefully received :-) Thanks, Neil -- Unless stated above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- diff --git a/src/share/classes/java/util/Vector.java b/src/share/classes/java/util/Vector.java --- a/src/share/classes/java/util/Vector.java +++ b/src/share/classes/java/util/Vector.java @@ -1053,10 +1053,20 @@ * is, serialize it). This method is present merely for synchronization. * It just calls the default writeObject method. */ - private synchronized void writeObject(java.io.ObjectOutputStream s) + private void writeObject(java.io.ObjectOutputStream s) throws java.io.IOException { - s.defaultWriteObject(); + final java.io.ObjectOutputStream.PutField fields = s.putFields(); + Object[] data = null; + synchronized (this) { + fields.put("capacityIncrement", capacityIncrement); + fields.put("elementCount", elementCount); + final int dataLength = elementData.length; + data = new Object[dataLength]; + System.arraycopy(elementData, 0, data, 0, dataLength); + } + fields.put("elementData", data); + s.writeFields(); } /** diff --git a/test/java/util/Vector/SerializationDeadlock.java b/test/java/util/Vector/SerializationDeadlock.java new file mode 100644 --- /dev/null +++ b/test/java/util/Vector/SerializationDeadlock.java @@ -0,0 +1,111 @@ +/* + * @test + * @bug 6934356 + * @summary Serializing Vector objects which refer to each other should not be able to deadlock. + * @author Neil Richards + */ + +import java.io.ByteArrayOutputStream; +import java.io.IOException; +import java.io.ObjectOutputStream; +import java.io.Serializable; +import java.util.ArrayList; +import java.util.Vector; +import java.util.concurrent.CyclicBarrier; +import java.util.concurrent.TimeoutException; +import java.util.concurrent.TimeUnit; + +public class SerializationDeadlock { + public static void main(final String[] args) { + // Test for Vector serialization deadlock + final Vector v1 = new Vector(); + final Vector v2 = new Vector(); + final TestBarrier testStart = new TestBarrier(3); + + v1.add(testStart); + v1.add(v2); + v2.add(testStart); + v2.add(v1); + + final CyclicBarrier testEnd = new CyclicBarrier(3); + final TestThread t1 = new TestThread(v1, testEnd); + final TestThread t2 = new TestThread(v2, testEnd); + + t1.start(); + t2.start(); + + try { + testStart.await(); + testEnd.await(1, TimeUnit.SECONDS); + } catch (TimeoutException te) { + throw new RuntimeException("Test FAILED: Probable serialization deadlock detected"); + } catch (Exception e) { + throw new RuntimeException("Test ERROR: Unexpected exception caught", e); + } + + TestThread.handleExceptions(); + } + + static final class TestBarrier extends CyclicBarrier + implements Serializable { + public TestBarrier(final int count) { + super(count); + } + + private void writeObject(final ObjectOutputStream oos) + throws IOException { + oos.defaultWriteObject(); + // Wait until all TestThreads have started serializing data + try { + await(); + } catch (final Exception e) { + throw new IOException("Test ERROR: Unexpected exception caught", e); + } + } + } + + static final class TestThread extends Thread { + private static final ArrayList exceptions = new ArrayList(); + + private final Vector vector; + private final CyclicBarrier testEnd; + + public TestThread(final Vector vector, final CyclicBarrier testEnd) { + this.vector = vector; + this.testEnd = testEnd; + setDaemon(true); + } + + public void run() { + try { + final ByteArrayOutputStream baos = new ByteArrayOutputStream(); + final ObjectOutputStream oos = new ObjectOutputStream(baos); + + oos.writeObject(vector); + oos.close(); + } catch (final IOException ioe) { + addException(ioe); + } finally { + try { + testEnd.await(); + } catch (Exception e) { + addException(e); + } + } + } + + private static synchronized void addException(final Exception exception) { + exceptions.add(exception); + } + + public static synchronized void handleExceptions() { + if (false == exceptions.isEmpty()) { + for (Exception exception : exceptions) { + exception.printStackTrace(); + } + throw new RuntimeException("Test ERROR: Unexpected exceptions thrown on test threads - see stderr for details"); + } + } + } +} + From Alan.Bateman at oracle.com Mon Dec 13 18:46:42 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Dec 2010 18:46:42 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: Message-ID: <4D066A12.9090006@oracle.com> Neil Richards wrote: > Hello. > > I have a fix and testcase for problem 6934356 in the Java bug database > - "Vector.writeObject() synchronization risks serialization deadlock". > I've included the 'hg diff -g' output below. > > I'm new to OpenJDK - though not to Java SE implementation development > - so hope that this is correct mailing list to ask for the code to be > reviewed. > (Please point me towards a better list if this is not so). > This is the right place, welcome! First we should probably establish if you are a contributer or not. Your mail hints that you are in IBM but it's impossible to verify from the mail address. I haven't looked at your patch in detail yet but I suspect there may be similar issues in other places (like j.u.Hashtable) once you are done with Vector. -Alan. From mike.duigou at oracle.com Mon Dec 13 18:56:21 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 13 Dec 2010 10:56:21 -0800 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: Message-ID: <6EF8B223-29AA-48F8-82A0-ABFA38E94DE1@oracle.com> On Dec 13 2010, at 09:59 , Neil Richards wrote: > Hello. > > I have a fix and testcase for problem 6934356 in the Java bug database > - "Vector.writeObject() synchronization risks serialization deadlock". > I've included the 'hg diff -g' output below. To incorporate any fix it's necessary to have an SCA (Source Contributor Agreement) in place. I am unsure of the status of things with IBM joining OpenJDK and whether there's a blanket SCA for all IBM contributions in place yet. Additionally confirmation would be needed that you are an IBM employee (mail from an IBM domain) and authorized to contribute to OpenJDK. Contact me directly if you need assistance sorting out the contributing rights. > I'm new to OpenJDK - though not to Java SE implementation development > - so hope that this is correct mailing list to ask for the code to be > reviewed. This is the place! > Also, given that this is a reported bug in the Java bug database, I'm > a little confused as to whether I need to additionally raise it in > https://bugs.openjdk.java.net/ This should be sufficient. > And, indeed, whether it is better for me to include the 'hg diff -g' > output inline, as I have done below, or as an attachment, or in some > other fashion. In this case the patch appears to have arrived intact. There is always some risk of mangling by the mail list software or intermediate mail agents and clients which is generally why patches are included as attachments. Mike From SPOOLE at uk.ibm.com Mon Dec 13 19:13:28 2010 From: SPOOLE at uk.ibm.com (Steve Poole) Date: Mon, 13 Dec 2010 19:13:28 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <6EF8B223-29AA-48F8-82A0-ABFA38E94DE1@oracle.com> References: <6EF8B223-29AA-48F8-82A0-ABFA38E94DE1@oracle.com> Message-ID: My understanding is that the necessary contribution agreements have been completed and that Neil and myself have been officially sanctioned by IBM and Oracle management to participate and contribute to OpenJDK. Of course you'll have to check with your management but as far as the two of us are concerned we're all squared away. Regards Steve Poole From: Mike Duigou To: core-libs-dev Date: 13/12/2010 18:58 Subject: Re: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock Sent by: core-libs-dev-bounces at openjdk.java.net On Dec 13 2010, at 09:59 , Neil Richards wrote: > Hello. > > I have a fix and testcase for problem 6934356 in the Java bug database > - "Vector.writeObject() synchronization risks serialization deadlock". > I've included the 'hg diff -g' output below. To incorporate any fix it's necessary to have an SCA (Source Contributor Agreement) in place. I am unsure of the status of things with IBM joining OpenJDK and whether there's a blanket SCA for all IBM contributions in place yet. Additionally confirmation would be needed that you are an IBM employee (mail from an IBM domain) and authorized to contribute to OpenJDK. Contact me directly if you need assistance sorting out the contributing rights. > I'm new to OpenJDK - though not to Java SE implementation development > - so hope that this is correct mailing list to ask for the code to be > reviewed. This is the place! > Also, given that this is a reported bug in the Java bug database, I'm > a little confused as to whether I need to additionally raise it in > https://bugs.openjdk.java.net/ This should be sufficient. > And, indeed, whether it is better for me to include the 'hg diff -g' > output inline, as I have done below, or as an attachment, or in some > other fashion. In this case the patch appears to have arrived intact. There is always some risk of mangling by the mail list software or intermediate mail agents and clients which is generally why patches are included as attachments. Mike From mark.reinhold at oracle.com Mon Dec 13 19:46:21 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Dec 2010 11:46:21 -0800 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: spoole@uk.ibm.com; Mon, 13 Dec 2010 19:13:28 GMT; Message-ID: <20101213194621.A761013A8@eggemoggin.niobe.net> > From: Steve Poole > Date: Mon, 13 Dec 2010 19:13:28 +0000 > > My understanding is that the necessary contribution agreements have been > completed and that Neil and myself have been officially sanctioned by IBM > and Oracle management to participate and contribute to OpenJDK. Yes, that's correct -- contributions from IBM employees are already covered. No further paperwork is required. (It would make things clearer if Neil had used an ibm.com address, but perhaps he has reasons not to do so.) - Mark From neil.richards at ngmr.net Mon Dec 13 20:04:44 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 13 Dec 2010 20:04:44 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <4D066A12.9090006@oracle.com> References: <4D066A12.9090006@oracle.com> Message-ID: On 13 December 2010 18:46, Alan Bateman wrote: > This is the right place, welcome! > First we should probably establish if you are a contributer or not. Your > mail hints that you are in IBM but it's impossible to verify from the mail > address. Hi Alan, I've sent you and Mike a separate email from my IBM address to confirm my "IBM-ness". :-) > I haven't looked at your patch in detail yet but I suspect there may be > similar issues in other places (like j.u.Hashtable) once you are done with > Vector. You are correct, there is a similar issue in Hashtable. I'm currently in the process of working up another fix and testcase for that, which I hope to submit separately shortly. Cheers, Neil -- Unless stated above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Mon Dec 13 20:38:39 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 13 Dec 2010 20:38:39 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <20101213194621.A761013A8@eggemoggin.niobe.net> References: <20101213194621.A761013A8@eggemoggin.niobe.net> Message-ID: On 13 December 2010 19:46, wrote: > (It would make things clearer if Neil had used an ibm.com address, but > ?perhaps he has reasons not to do so.) I'm sorry for sowing confusion :-( I'm using a different email address is mainly for easy book-keeping (on my part) - to separate OpenJDK conversations from anything/everything else. Cheers, Neil -- Unless stated above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From xueming.shen at oracle.com Mon Dec 13 22:15:40 2010 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 13 Dec 2010 22:15:40 +0000 Subject: hg: jdk7/tl/jdk: 7003462: cannot read InputStream returned by java.util.ZipFile.getInputStream(ZipEntry) Message-ID: <20101213221549.E2C4D4736B@hg.openjdk.java.net> Changeset: 1740ad242f56 Author: sherman Date: 2010-12-13 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1740ad242f56 7003462: cannot read InputStream returned by java.util.ZipFile.getInputStream(ZipEntry) Summary: The returned InflatedInputStream object should be kept in map streams Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/FinalizeInflater.java From bhavesh.patel at sun.com Mon Dec 13 22:38:52 2010 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Mon, 13 Dec 2010 22:38:52 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20101213223856.B10854736D@hg.openjdk.java.net> Changeset: ffbf2b2a8611 Author: bpatel Date: 2010-12-13 13:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ffbf2b2a8611 7006270: Several javadoc regression tests are failing on windows Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java Changeset: 2f2ead61db06 Author: bpatel Date: 2010-12-13 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2f2ead61db06 Merge - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java From joe.darcy at oracle.com Mon Dec 13 23:05:14 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 13 Dec 2010 23:05:14 +0000 Subject: hg: jdk7/tl/jdk: 7006129: Project Coin: Annotation type to reduce varargs warnings Message-ID: <20101213230523.C1FAF4736F@hg.openjdk.java.net> Changeset: 78885e69c42c Author: darcy Date: 2010-12-13 14:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78885e69c42c 7006129: Project Coin: Annotation type to reduce varargs warnings Reviewed-by: jjg, mcimadamore ! make/java/java/FILES_java.gmk + src/share/classes/java/lang/SafeVarargs.java From joe.darcy at oracle.com Mon Dec 13 23:06:00 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 13 Dec 2010 23:06:00 +0000 Subject: hg: jdk7/tl/langtools: 6993978: Project Coin: Compiler support of annotation to reduce varargs warnings Message-ID: <20101213230602.8AAD547370@hg.openjdk.java.net> Changeset: 7b99f98b3035 Author: mcimadamore Date: 2010-12-13 15:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7b99f98b3035 6993978: Project Coin: Compiler support of annotation to reduce varargs warnings Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/RunExamples.java + test/tools/javac/diags/examples/TrustMeOnNonVarargsMeth.java + test/tools/javac/diags/examples/TrustMeOnReifiableVarargsParam.java + test/tools/javac/diags/examples/TrustMeOnVirtualMethod.java ! test/tools/javac/diags/examples/UncheckedGenericArrayCreation.java + test/tools/javac/diags/examples/UnsafeUseOfVarargsParam.java - test/tools/javac/diags/examples/VarargsFilename.java - test/tools/javac/diags/examples/VarargsFilenameAdditional.java ! test/tools/javac/diags/examples/VarargsNonReifiableType.java - test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java ! test/tools/javac/varargs/6730476/T6730476a.java ! test/tools/javac/varargs/6806876/T6806876.out + test/tools/javac/varargs/6993978/T6993978neg.java + test/tools/javac/varargs/6993978/T6993978neg.out ! test/tools/javac/varargs/warning/Warn4.java + test/tools/javac/varargs/warning/Warn5.java From chris.hegarty at oracle.com Tue Dec 14 15:07:16 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Dec 2010 15:07:16 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown Message-ID: <4D078824.5030307@oracle.com> Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and java.util.Formatter multi-arg constructors that take a java.io.File or String filename (as well as one or more additional args) opens a FileIn/OutputStream to the given File/filename. If one of the other given args causes the constructor to fail ( null or unsupported charset for example ) the FileIn/OutputStream is never closed, and the application does not have a reference to it. You rely on the finalizer to close the stream. This is most serious on Windows because you cannot remove a file if there is an open handle to it. I also cleaned up an existing regression test that fails in samevm mode (partly) because of this. And removed another excluded test from the list since its bug was fixed some time ago. Webrev: http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ -Chris. From kumar.x.srinivasan at oracle.com Tue Dec 14 15:42:27 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 14 Dec 2010 15:42:27 +0000 Subject: hg: jdk7/tl/jdk: 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.* Message-ID: <20101214154244.BEF1A47395@hg.openjdk.java.net> Changeset: 6d3fb387da8e Author: ksrini Date: 2010-12-14 07:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6d3fb387da8e 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.* Reviewed-by: mduigou, briangoetz ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/classes/java/util/jar/Pack200.java From kumar.x.srinivasan at oracle.com Tue Dec 14 16:14:09 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 14 Dec 2010 16:14:09 +0000 Subject: hg: jdk7/tl/jdk: 7006704: (pack200) add missing file for 6990106 Message-ID: <20101214161418.D473247397@hg.openjdk.java.net> Changeset: 68cc30a3a1fd Author: ksrini Date: 2010-12-14 08:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/68cc30a3a1fd 7006704: (pack200) add missing file for 6990106 Reviewed-by: mduigou, briangoetz + src/share/classes/com/sun/java/util/jar/pack/FixedList.java From Alan.Bateman at oracle.com Tue Dec 14 18:03:48 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Dec 2010 18:03:48 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D078824.5030307@oracle.com> References: <4D078824.5030307@oracle.com> Message-ID: <4D07B184.7050005@oracle.com> Chris Hegarty wrote: > Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, > and java.util.Formatter multi-arg constructors that take a > java.io.File or String filename (as well as one or more additional > args) opens a FileIn/OutputStream to the given File/filename. If one > of the other given args causes the constructor to fail ( null or > unsupported charset for example ) the FileIn/OutputStream is never > closed, and the application does not have a reference to it. You rely > on the finalizer to close the stream. > > This is most serious on Windows because you cannot remove a file if > there is an open handle to it. > > I also cleaned up an existing regression test that fails in samevm > mode (partly) because of this. And removed another excluded test from > the list since its bug was fixed some time ago. > > Webrev: > http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ > > -Chris. It would be good to get this one fixed. If I understand the proposal correctly, there may still be side effects when NPE or UnsupportedEncodingException is thrown. When I say "side effects" I mean that an empty file may be created or an existing file truncated before the exception is thrown. I wonder you've tried to extend the list of parameters to the private constructors to avoid this. A toCharset(String) method should be used to lookup the Charset for example rather than having OutputStreamWriter to do it. One minor comment is that I see that PrintStream is using java.util.Objects. Nice to see it being used but I wonder about loading yet another class during startup (System.out and err are PrintStreams and are initialized early in the startup). -Alan From schlosna at gmail.com Tue Dec 14 19:14:57 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Tue, 14 Dec 2010 14:14:57 -0500 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D078824.5030307@oracle.com> References: <4D078824.5030307@oracle.com> Message-ID: Chris, In src/share/classes/java/util/Formatter.java, shouldn't lines 1977 and 2084 also use wrapFileOutputStream? 1975 public Formatter(String fileName) throws FileNotFoundException { 1976 this(Locale.getDefault(Locale.Category.FORMAT), 1977 wrapFileOutputStream(new FileOutputStream(fileName))); 1978 } 2082 public Formatter(File file) throws FileNotFoundException { 2083 this(Locale.getDefault(Locale.Category.FORMAT), 2084 wrapFileOutputStream(new FileOutputStream(file))); 2085 } - Dave On Tue, Dec 14, 2010 at 10:07 AM, Chris Hegarty wrote: > Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and > java.util.Formatter multi-arg constructors that take a java.io.File or > String filename (as well as one or more additional args) opens a > FileIn/OutputStream to the given File/filename. If one of the other given > args causes the constructor to fail ( null or unsupported charset for > example ) the FileIn/OutputStream is never closed, and the application does > not have a reference to it. You rely on the finalizer to close the stream. > > This is most serious on Windows because you cannot remove a file if there is > an open handle to it. > > I also cleaned up an existing regression test that fails in samevm mode > (partly) because of this. And removed another excluded test from the list > since its bug was fixed some time ago. > > Webrev: > ?http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ > > -Chris. > From jim.holmlund at sun.com Tue Dec 14 19:41:35 2010 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 14 Dec 2010 19:41:35 +0000 Subject: hg: jdk7/tl/langtools: 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux Message-ID: <20101214194138.895EC4739F@hg.openjdk.java.net> Changeset: a8d3eed8e247 Author: jjh Date: 2010-12-13 17:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a8d3eed8e247 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux Summary: Fixed JavacFileManager to not treat a non-existant pathname as a directory. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java From linuxhippy at gmail.com Tue Dec 14 20:37:07 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Tue, 14 Dec 2010 21:37:07 +0100 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: <4CEA910F.7050009@cs.oswego.edu> References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> <4CEA87CA.5090108@cs.oswego.edu> <4CEA8C4E.7020802@oracle.com> <4CEA8F25.4060500@oracle.com> <4CEA910F.7050009@cs.oswego.edu> Message-ID: > I've also been concerned about performance. As I understand it, but maybe > I have > it wrong, is that the JLS [1] doesn't allow this when changing final > fields > after an object is constructed. But don't we have the same overhead at object construction time? I remember having read somewhere the JVM issues fence/barrier instructions after an object has been created? - Clemens From lance.andersen at oracle.com Tue Dec 14 21:09:24 2010 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 14 Dec 2010 21:09:24 +0000 Subject: hg: jdk7/tl/jdk: 7006454: Typo in javadocs typo for Statement.executeBatch @since Message-ID: <20101214210934.8F01F473A3@hg.openjdk.java.net> Changeset: a72e7147816f Author: lancea Date: 2010-12-14 16:08 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a72e7147816f 7006454: Typo in javadocs typo for Statement.executeBatch @since Reviewed-by: alanb ! src/share/classes/java/sql/Statement.java From jonathan.gibbons at oracle.com Tue Dec 14 22:18:00 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 14 Dec 2010 22:18:00 +0000 Subject: hg: jdk7/tl/langtools: 6999891: DefaultFileManager incorrect Message-ID: <20101214221802.6EE6D473A7@hg.openjdk.java.net> Changeset: 0141f508b98d Author: jjg Date: 2010-12-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0141f508b98d 6999891: DefaultFileManager incorrect Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/processing/filer/TestValidRelativeNames.java From David.Holmes at oracle.com Tue Dec 14 23:29:00 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 15 Dec 2010 09:29:00 +1000 Subject: 6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization In-Reply-To: References: <4CEA75AC.9000803@oracle.com> <4CEA7FB8.2030401@univ-mlv.fr> <4CEA87CA.5090108@cs.oswego.edu> <4CEA8C4E.7020802@oracle.com> <4CEA8F25.4060500@oracle.com> <4CEA910F.7050009@cs.oswego.edu> Message-ID: <4D07FDBC.40302@oracle.com> Clemens Eisserer said the following on 12/15/10 06:37: >> I've also been concerned about performance. As I understand it, but maybe >> I have >> it wrong, is that the JLS [1] doesn't allow this when changing final >> fields >> after an object is constructed. > > But don't we have the same overhead at object construction time? > I remember having read somewhere the JVM issues fence/barrier > instructions after an object has been created? The barrier needed for "final-freeze" is a one-off barrier at the end of construction. Brian was asking if we could use a one-off barrier at the end of deserialization. Alan points out that technically that's not allowed as the JLS states there must be a freeze after each modification via "reflection or other special mechanisms". But I wonder if the JLS might not be being flexible enough in this case. If the object being deserialized is not visible until deserialization completes then you don't need a "freeze" until deserialization completes. Anyway this "simple fix" is now somewhat contentious and not-simple and therefore not likely to proceed in the near future. David From alan.bateman at oracle.com Wed Dec 15 09:16:05 2010 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 15 Dec 2010 09:16:05 +0000 Subject: hg: jdk7/tl/jdk: 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible violation of JNI spec Message-ID: <20101215091614.AD773473C2@hg.openjdk.java.net> Changeset: 0ef137ae6f3b Author: alanb Date: 2010-12-15 09:15 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0ef137ae6f3b 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible violation of JNI spec Reviewed-by: ohair, alanb Contributed-by: spoole at uk.ibm.com ! src/share/demo/jvmti/heapTracker/heapTracker.c From chris.hegarty at oracle.com Wed Dec 15 13:56:17 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Dec 2010 13:56:17 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: References: <4D078824.5030307@oracle.com> Message-ID: <4D08C901.1000108@oracle.com> Hi Dave, > In src/share/classes/java/util/Formatter.java, shouldn't lines 1977 > and 2084 also use wrapFileOutputStream? No, I don't believe it is necessary to use wrapFileOutputStream for these since the OutputStreamWriter constructor can never fail here (therefore we will never need to close the file stream). The OutputStreamWrite constructor can only fail ( in this cases ) when null is passed as the charset name, or an unsupported charset name is paseed. I am going to rework the fix as per Alan's comments [1]. Instead of checking that the OutputStreamWriter has been successfully constructed we can verify the passed arguments before creating the file stream. Thanks, -Chris. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005453.html > 1975 public Formatter(String fileName) throws FileNotFoundException { > 1976 this(Locale.getDefault(Locale.Category.FORMAT), > 1977 wrapFileOutputStream(new FileOutputStream(fileName))); > 1978 } > > 2082 public Formatter(File file) throws FileNotFoundException { > 2083 this(Locale.getDefault(Locale.Category.FORMAT), > 2084 wrapFileOutputStream(new FileOutputStream(file))); > 2085 } > > - Dave > > On Tue, Dec 14, 2010 at 10:07 AM, Chris Hegarty > wrote: >> Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and >> java.util.Formatter multi-arg constructors that take a java.io.File or >> String filename (as well as one or more additional args) opens a >> FileIn/OutputStream to the given File/filename. If one of the other given >> args causes the constructor to fail ( null or unsupported charset for >> example ) the FileIn/OutputStream is never closed, and the application does >> not have a reference to it. You rely on the finalizer to close the stream. >> >> This is most serious on Windows because you cannot remove a file if there is >> an open handle to it. >> >> I also cleaned up an existing regression test that fails in samevm mode >> (partly) because of this. And removed another excluded test from the list >> since its bug was fixed some time ago. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ >> >> -Chris. >> From jonathan.gibbons at oracle.com Wed Dec 15 14:40:02 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 Dec 2010 14:40:02 +0000 Subject: hg: jdk7/tl/langtools: 7006564: NPE in javac running test/tools/javac/nio/compileTest/CompileTest.java Message-ID: <20101215144004.B2514473D9@hg.openjdk.java.net> Changeset: cff0b8694633 Author: jjg Date: 2010-12-15 06:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cff0b8694633 7006564: NPE in javac running test/tools/javac/nio/compileTest/CompileTest.java Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java From chris.hegarty at oracle.com Wed Dec 15 21:03:19 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Dec 2010 21:03:19 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D07B184.7050005@oracle.com> References: <4D078824.5030307@oracle.com> <4D07B184.7050005@oracle.com> Message-ID: <4D092D17.3070001@oracle.com> On 12/14/10 06:03 PM, Alan Bateman wrote: > ..... > It would be good to get this one fixed. If I understand the proposal > correctly, there may still be side effects when NPE or > UnsupportedEncodingException is thrown. When I say "side effects" I mean > that an empty file may be created or an existing file truncated before > the exception is thrown. I wonder you've tried to extend the list of > parameters to the private constructors to avoid this. A > toCharset(String) method should be used to lookup the Charset for > example rather than having OutputStreamWriter to do it. > > One minor comment is that I see that PrintStream is using > java.util.Objects. Nice to see it being used but I wonder about loading > yet another class during startup (System.out and err are PrintStreams > and are initialized early in the startup). Thanks for your comments Alan. I reworked the changes to include them. Updated webrev: http://cr.openjdk.java.net/~chegar/7000511/webrev.01/webrev/ -Chris. > > -Alan From kumar.x.srinivasan at oracle.COM Wed Dec 15 22:45:13 2010 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 15 Dec 2010 14:45:13 -0800 Subject: review of simple pack200 fix Message-ID: <4D0944F9.7090907@oracle.COM> Hi, Could you please review this simple fix, it guards the switch value from a null. http://cr.openjdk.java.net/~ksrini/7007157/webrev.00/ Thanks Kumar From mike.duigou at oracle.com Wed Dec 15 23:10:22 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 15 Dec 2010 15:10:22 -0800 Subject: review of simple pack200 fix In-Reply-To: <4D0944F9.7090907@oracle.COM> References: <4D0944F9.7090907@oracle.COM> Message-ID: Under what circumstances is null returned and why is it safe to ignore it? Is the handling of null related to the lack of a default label on the switch? ie. It is intentional that action is only taken with the 3 specified commands and null is just in the set of cmd values requiring no special action. It makes me nervous whenever I see "pretend this never happened" handling for null. Mike On Dec 15 2010, at 14:45 , Kumar Srinivasan wrote: > Hi, > > Could you please review this simple fix, it guards the switch value from a null. > > http://cr.openjdk.java.net/~ksrini/7007157/webrev.00/ > > Thanks > Kumar > > > From stuart.marks at oracle.com Thu Dec 16 00:24:32 2010 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 15 Dec 2010 16:24:32 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries Message-ID: <4D095C40.4030100@oracle.com> Hi all, As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK libraries to use the new JDK 7 Coin features. The first feature is the diamond operator [2]. This first round of changes includes java.lang, java.io, java.sql, java.util, their corresponding tests, and related implementation files (exclusive of java.util.concurrent and related files). This change touches a total of 71 files. This is rather a lot of files, but the changes are all one-liners, and most files have only a few changes. Lance, please review the change to src/share/classes/java/sql/DriverManager.java. Joe, Alan, please review the rest of the changes. For the curious, I'm using a Jackpot-based automated converter to make bulk changes to large numbers of source files. I plan to do diamond conversion of a few other groups of JDK library packages before moving on to other Coin features. For verification, it turns out that diamond conversion doesn't change the bytecodes that are emitted by the compiler, so the resulting class files are byte-for-byte identical to class files from before the change. This should make us pretty confident that the changes don't break anything. Unfortunately, other Coin features will change bytecodes, so we won't be able to use this easy verification technique when we apply other Coin features. The webrev is here: http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/ A mercurial bundle suitable for "hg unbundle" is here: http://cr.openjdk.java.net/~smarks/reviews/6880112/bundle.0.hg Enjoy, s'marks [1] http://blogs.sun.com/darcy/entry/project_coin_minty_fresh_libraries [2] http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html From kumar.x.srinivasan at oracle.com Thu Dec 16 00:29:21 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 15 Dec 2010 16:29:21 -0800 Subject: review of simple pack200 fix In-Reply-To: References: <4D0944F9.7090907@oracle.COM> Message-ID: <4D095D61.4000006@oracle.COM> On 12/15/2010 3:10 PM, Mike Duigou wrote: > Under what circumstances is null returned and why is it safe to ignore it? Is the handling of null related to the lack of a default label on the switch? ie. It is intentional that action is only taken with the 3 specified commands and null is just in the set of cmd values requiring no special action. The latter ie. the 3 specified commands, if null continue with the processing with no special action, I have asked for a clarification of the behavior of nulls in the switch statement the current stand from the coin folks is that a value for null will throw an NPE. Kumar > It makes me nervous whenever I see "pretend this never happened" handling for null. > > Mike > > On Dec 15 2010, at 14:45 , Kumar Srinivasan wrote: > >> Hi, >> >> Could you please review this simple fix, it guards the switch value from a null. >> >> http://cr.openjdk.java.net/~ksrini/7007157/webrev.00/ >> >> Thanks >> Kumar >> >> >> From lance.andersen at oracle.com Thu Dec 16 00:44:44 2010 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 15 Dec 2010 19:44:44 -0500 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D095C40.4030100@oracle.com> References: <4D095C40.4030100@oracle.com> Message-ID: <85AFECB9-A307-4BF5-84E7-D90C960490A3@oracle.com> HI Stuart, The DriverManager change is fine. My Best, Lance On Dec 15, 2010, at 7:24 PM, Stuart Marks wrote: > Hi all, > > As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK libraries to use the new JDK 7 Coin features. The first feature is the diamond operator [2]. This first round of changes includes java.lang, java.io, java.sql, java.util, their corresponding tests, and related implementation files (exclusive of java.util.concurrent and related files). This change touches a total of 71 files. This is rather a lot of files, but the changes are all one-liners, and most files have only a few changes. > > Lance, please review the change to src/share/classes/java/sql/DriverManager.java. > > Joe, Alan, please review the rest of the changes. > > For the curious, I'm using a Jackpot-based automated converter to make bulk changes to large numbers of source files. I plan to do diamond conversion of a few other groups of JDK library packages before moving on to other Coin features. > > For verification, it turns out that diamond conversion doesn't change the bytecodes that are emitted by the compiler, so the resulting class files are byte-for-byte identical to class files from before the change. This should make us pretty confident that the changes don't break anything. Unfortunately, other Coin features will change bytecodes, so we won't be able to use this easy verification technique when we apply other Coin features. > > The webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/ > > A mercurial bundle suitable for "hg unbundle" is here: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/bundle.0.hg > > Enjoy, > > s'marks > > [1] http://blogs.sun.com/darcy/entry/project_coin_minty_fresh_libraries > > [2] http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html > From john.r.rose at oracle.com Thu Dec 16 00:43:16 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Dec 2010 16:43:16 -0800 Subject: review of simple pack200 fix In-Reply-To: <4D0944F9.7090907@oracle.COM> References: <4D0944F9.7090907@oracle.COM> Message-ID: <30560D3C-539F-4611-8EE3-5F4C0A7C5E8E@oracle.com> Reviewed, but the test case has an error; is it intentional? The CODE_ATTRIBUTE_PFX already ends with a dot '.', but you add another dot onto it. This will cause the declaration to be ineffectual, but in a non-obvious way. -- John On Dec 15, 2010, at 2:45 PM, Kumar Srinivasan wrote: > Hi, > > Could you please review this simple fix, it guards the switch value from a null. > > http://cr.openjdk.java.net/~ksrini/7007157/webrev.00/ > > Thanks > Kumar > > > From kumar.x.srinivasan at oracle.com Thu Dec 16 03:23:21 2010 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 15 Dec 2010 19:23:21 -0800 Subject: review of simple pack200 fix In-Reply-To: <30560D3C-539F-4611-8EE3-5F4C0A7C5E8E@oracle.com> References: <4D0944F9.7090907@oracle.COM> <30560D3C-539F-4611-8EE3-5F4C0A7C5E8E@oracle.com> Message-ID: <4D098629.2000002@oracle.COM> On 12/15/2010 4:43 PM, John Rose wrote: > Reviewed, but the test case has an error; is it intentional? No it isn't, I fixed it in my repo. Thanks kumar > The CODE_ATTRIBUTE_PFX already ends with a dot '.', but you add another dot onto it. This will cause the declaration to be ineffectual, but in a non-obvious way. > > -- John > > On Dec 15, 2010, at 2:45 PM, Kumar Srinivasan wrote: > >> Hi, >> >> Could you please review this simple fix, it guards the switch value from a null. >> >> http://cr.openjdk.java.net/~ksrini/7007157/webrev.00/ >> >> Thanks >> Kumar >> >> >> From David.Holmes at oracle.com Thu Dec 16 05:07:05 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 16 Dec 2010 15:07:05 +1000 Subject: review of simple pack200 fix In-Reply-To: References: <4D0944F9.7090907@oracle.COM> Message-ID: <4D099E79.1010407@oracle.com> Hi Mike, Mike Duigou said the following on 12/16/10 09:10: > Under what circumstances is null returned and why is it safe to ignore it? Is the handling of null related to the lack of a default label on the switch? ie. It is intentional that action is only taken with the 3 specified commands and null is just in the set of cmd values requiring no special action. > > It makes me nervous whenever I see "pretend this never happened" handling for null. You need to know the history here. Originally the code was: + if (attrCommands != null) { + Object lkey = Attribute.keyForLookup(ctype, name); + String cmd = (String) attrCommands.get(lkey); + if (cmd == "pass") { + String message = "passing attribute bitwise in "+h; + throw new Attribute.FormatException(message, ctype, name, + cmd); + } else if (cmd == "error") { + String message = "attribute not allowed in "+h; + throw new Attribute.FormatException(message, ctype, name, + cmd); + } else if (cmd == "strip") { + skip(length, name+" attribute in "+h); + continue; + } + } then at some point (which doesn't seem to have filtered through to the repo I clone) the if/else was changed to the switch, but the switch didn't account for the possibility there may not be a cmd for a particular case. Cheers, David > Mike > > On Dec 15 2010, at 14:45 , Kumar Srinivasan wrote: > >> Hi, >> >> Could you please review this simple fix, it guards the switch value from a null. >> >> http://cr.openjdk.java.net/~ksrini/7007157/webrev.00/ >> >> Thanks >> Kumar >> >> >> > From xuelei.fan at oracle.com Thu Dec 16 06:44:12 2010 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 16 Dec 2010 06:44:12 +0000 Subject: hg: jdk7/tl/jdk: 7006265: Javadoc warnings Message-ID: <20101216064435.1783347413@hg.openjdk.java.net> Changeset: e6ed7c95d94f Author: xuelei Date: 2010-12-15 22:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6ed7c95d94f 7006265: Javadoc warnings Reviewed-by: weijun ! src/share/classes/javax/net/ssl/X509ExtendedTrustManager.java From Alan.Bateman at oracle.com Thu Dec 16 08:45:23 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Dec 2010 08:45:23 +0000 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D095C40.4030100@oracle.com> References: <4D095C40.4030100@oracle.com> Message-ID: <4D09D1A3.9030308@oracle.com> Stuart Marks wrote: > Hi all, > > As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK > libraries to use the new JDK 7 Coin features. The first feature is the > diamond operator [2]. This first round of changes includes java.lang, > java.io, java.sql, java.util, their corresponding tests, and related > implementation files (exclusive of java.util.concurrent and related > files). This change touches a total of 71 files. This is rather a lot > of files, but the changes are all one-liners, and most files have only > a few changes. > > Lance, please review the change to > src/share/classes/java/sql/DriverManager.java. > > Joe, Alan, please review the rest of the changes. > > For the curious, I'm using a Jackpot-based automated converter to make > bulk changes to large numbers of source files. I plan to do diamond > conversion of a few other groups of JDK library packages before moving > on to other Coin features. > > For verification, it turns out that diamond conversion doesn't change > the bytecodes that are emitted by the compiler, so the resulting class > files are byte-for-byte identical to class files from before the > change. This should make us pretty confident that the changes don't > break anything. Unfortunately, other Coin features will change > bytecodes, so we won't be able to use this easy verification technique > when we apply other Coin features. > > The webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/ Looks good to me, and very easy to review. One question on this. There are a couple of places where the original statement was "too long" to fit on a single line so the RHS of the assignment was pushed into a second line. With diamond it means that the statement could fit on a single line. Examples are in java.lang.Character at L649 and the changes to java.lang.Package. It's purely a style thing but I wonder if the automated converter can do this re-formating or whether we just leave it for future maintenance in the respective area? -Alan. From brian.goetz at oracle.com Thu Dec 16 09:29:52 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 16 Dec 2010 10:29:52 +0100 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D09D1A3.9030308@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> Message-ID: <52A156A1-B8E5-4A82-B870-31600FAF9F5C@oracle.com> >> http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/ > Looks good to me, and very easy to review. > > One question on this. There are a couple of places where the original statement was "too long" to fit on a single line so the RHS of the assignment was pushed into a second line. With diamond it means that the statement could fit on a single line. Examples are in java.lang.Character at L649 and the changes to java.lang.Package. It's purely a style thing but I wonder if the automated converter can do this re-formating or whether we just leave it for future maintenance in the respective area? I noticed a lot of these when I was test-running the refactoring to use foreach -- there are a lot of lines that for whaever reason, are spread out over multiple lines even though they could easily be combined. Are there reasons to avoid fixing these when we're touching the code? From Alan.Bateman at oracle.com Thu Dec 16 09:57:06 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Dec 2010 09:57:06 +0000 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <52A156A1-B8E5-4A82-B870-31600FAF9F5C@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <52A156A1-B8E5-4A82-B870-31600FAF9F5C@oracle.com> Message-ID: <4D09E272.802@oracle.com> Brian Goetz wrote: > : > Are there reasons to avoid fixing these when we're touching the code? I can't think of any reasons. It's mostly a question as to whether the automated refactoring can do this or whether we should "fix up" such cases manually. I only spotted a few when reviewing this patch so it's not a major issue this time. -Alan From Alan.Bateman at oracle.com Thu Dec 16 11:46:57 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Dec 2010 11:46:57 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D092D17.3070001@oracle.com> References: <4D078824.5030307@oracle.com> <4D07B184.7050005@oracle.com> <4D092D17.3070001@oracle.com> Message-ID: <4D09FC31.1070501@oracle.com> Chris Hegarty wrote: > > : > Thanks for your comments Alan. I reworked the changes to include them. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/7000511/webrev.01/webrev/ This looks better. A few comments: In PrintStream it looks like the charset will now be checked twice, once by using isSupported and again when creating the OutputStreamWriter. As OutputStreamWriter has a constructor that takes a Charset (and so doesn't throw UnsupportedEncodingException) then maybe it would be simpler to just replace verifyCharsetName with a toCharset(String) method that does the Charset.forName and returns the Charset. If you did that, and introduced a private constructor that takes the Charset as its first parameter then it might be cleaner. Same thing in PrinterWriter and Formatter and you would avoid the Void parameter trick that might not be clear to future maintainers. Minor nit is that the new private constructor in PrinterWriter might be better placed before the public constructors that use it. Also minor comment on Formatter is that the private static getZero method is declared final :-) On Scanner there is one other constructor that has the same issue (line 726). On the tests, it's nice to see multi-catch being used in test/java/util/Formatter/Constructors.java. It might be good to add the bugID for future archaeologists trying to understand the behavior change where UnsupportedEncodingException is thrown instead of FNF. -Alan. From Alan.Bateman at oracle.com Thu Dec 16 13:01:10 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Dec 2010 13:01:10 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: Message-ID: <4D0A0D96.7050302@oracle.com> Neil Richards wrote: > Hello. > > I have a fix and testcase for problem 6934356 in the Java bug database > - "Vector.writeObject() synchronization risks serialization deadlock". > I've included the 'hg diff -g' output below. > I've looked at the patch and don't see anything obviously wrong. I think Mike might is looking at it too. It clearly comes with a performance cost of course. One small comment is that the fields are partly populated in the synchronized block and partly outside. It might be cleaner to take a copy of the capacity increment and element count in the synchronized block and then set all the fields together outside. Another minor comment is the "final"s don't seem to be needed. On the test case, it needs the GPL header. There are templates in the repository and you'll also see tests contributed by RedHat and Google if that helps. Another thing to mention is that hard-coded timeouts are problematic. In this case a 1s timeout might not be sufficient when on a machine that is running many tests concurrently. One suggestion is to just leave the threads deadlock and the test will timeout and fail if the bug exists. -Alan. From Ulf.Zibis at gmx.de Thu Dec 16 13:15:50 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 16 Dec 2010 14:15:50 +0100 Subject: coin features in JDK-7 or JDK-8 ? In-Reply-To: <4D095C40.4030100@oracle.com> References: <4D095C40.4030100@oracle.com> Message-ID: <4D0A1106.9000508@gmx.de> Hi all, in the recent issue of the German "Java Spektrum" I read, that the project coin features are scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too) Now I'm wondering, as the coin features are already in the JDK-7 codebase. Can someone clarify ? -Ulf From brian.goetz at oracle.com Thu Dec 16 13:27:18 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 16 Dec 2010 14:27:18 +0100 Subject: coin features in JDK-7 or JDK-8 ? In-Reply-To: <4D0A1106.9000508@gmx.de> References: <4D095C40.4030100@oracle.com> <4D0A1106.9000508@gmx.de> Message-ID: Coin is part of Java 7. There may be *more* Coin features ("Coin: the flip side") coming in 8. On Dec 16, 2010, at 2:15 PM, Ulf Zibis wrote: > Hi all, > > in the recent issue of the German "Java Spektrum" I read, that the project coin features are > scheduled for JDK-8 2012 (Plan B). (Jigsaw and Lambda too) > > Now I'm wondering, as the coin features are already in the JDK-7 codebase. > > Can someone clarify ? > > -Ulf > > From sundararajan.a at sun.com Thu Dec 16 15:23:37 2010 From: sundararajan.a at sun.com (sundararajan.a at sun.com) Date: Thu, 16 Dec 2010 15:23:37 +0000 Subject: hg: jdk7/tl/jdk: 6980447: Rhino JavaScript engine code in jdk-7 has to updated with the latest code from Rhino 1.7R3. Message-ID: <20101216152346.560744742F@hg.openjdk.java.net> Changeset: e67a399dd4ad Author: sundar Date: 2010-12-16 20:52 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e67a399dd4ad 6980447: Rhino JavaScript engine code in jdk-7 has to updated with the latest code from Rhino 1.7R3. Summary: Updating Rhino javascript engine with version 1.7R3. Issue 6427783 (E4X support is missing from Sun's Mozilla JavaScript implementation) is also fixed as a side-effect. Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java ! src/share/classes/com/sun/script/javascript/RhinoTopLevel.java ! src/share/classes/com/sun/tools/script/shell/init.js - test/javax/script/E4XErrorTest.java ! test/javax/script/VersionTest.java From neil.richards at ngmr.net Thu Dec 16 16:24:56 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 16 Dec 2010 16:24:56 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <4D0A0D96.7050302@oracle.com> References: <4D0A0D96.7050302@oracle.com> Message-ID: On 16 December 2010 13:01, Alan Bateman wrote: > I've looked at the patch and don't see anything obviously wrong. I think > Mike might is looking at it too. It clearly comes with a performance cost of > course. I've tried to write the fix so that the cost is minimized. >?One small comment is that the fields are partly populated in the > synchronized block and partly outside. It might be cleaner to take a copy of > the capacity increment and element count in the synchronized block and then > set all the fields together outside. I guess I did as little data copying as was necessary to make the fix, to minimize its performance cost. > Another minor comment is the "final"s > don't seem to be needed. Yeah, I admit my tendency to declare variables as 'final' (where they can be) is a little idiosyncratic. I find that the use of 'final' helps to make (reading) the code clearer - once you've seen a field/variable is final, you're happy it's not going to change. Also, I suspect declaring things as 'final' might also give extra clues to JITs on how to optimally compile the code. > On the test case, it needs the GPL header. There are templates in the > repository and you'll also see tests contributed by RedHat and Google if > that helps. Ah, sorry. I'll work on getting the right words in there, and will attach a modified changeset as soon as I have it sorted. > Another thing to mention is that hard-coded timeouts are > problematic. In this case a 1s timeout might not be sufficient when on a > machine that is running many tests concurrently. One suggestion is to just > leave the threads deadlock and the test will timeout and fail if the bug > exists. Yes, I worried over the timeout aspect of the testcase, too. I had guessed that a testcase that hung forever was worse behaved than one which reported failure after a certain timeout period - at least, when the hang is the expected failure mode for the test. But I see that it can be sensitive to the load on the machine it's being run on. So I'm happy to modify the test if the jtreg test harness deals with cleaning up hanging tests, reporting them as failures. Cheers, Neil -- Unless stated above: Work email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Thu Dec 16 16:39:51 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 16 Dec 2010 16:39:51 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D066A12.9090006@oracle.com> Message-ID: On 13 December 2010 20:04, Neil Richards wrote: > On 13 December 2010 18:46, Alan Bateman wrote: >> I haven't looked at your patch in detail yet but I suspect there may be >> similar issues in other places (like j.u.Hashtable) once you are done with >> Vector. > > You are correct, there is a similar issue in Hashtable. > I'm currently in the process of working up another fix and testcase > for that, which I hope to submit separately shortly. I now notice that there isn't a bug in Java bug database exactly for the problem in Hashtable - though it's obviously related to 6934356, and to 4741471 (which removed writeObject() synchronization from the unsynchronized collection classes). (As in Vector, the problem in Hashtable has existed since 1.4). In this case, can I raise an entry in the OpenJDK bug database for the problem in Hashtable, or do I need to get it raised in the Java bug database? Any guidance gratefully received, Thanks, Neil PS: What is the standard way of referring to a bug from one system or the other? Or are the bug numbers from each system sufficiently far apart to avoid ambiguity that way? -- Unless stated above: Work email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From joe.darcy at oracle.com Thu Dec 16 16:41:26 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Dec 2010 08:41:26 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D095C40.4030100@oracle.com> References: <4D095C40.4030100@oracle.com> Message-ID: <4D0A4136.7070700@oracle.com> On 12/15/2010 4:24 PM, Stuart Marks wrote: > Hi all, > > As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK > libraries to use the new JDK 7 Coin features. The first feature is the > diamond operator [2]. This first round of changes includes java.lang, > java.io, java.sql, java.util, their corresponding tests, and related > implementation files (exclusive of java.util.concurrent and related > files). This change touches a total of 71 files. This is rather a lot > of files, but the changes are all one-liners, and most files have only > a few changes. > > Lance, please review the change to > src/share/classes/java/sql/DriverManager.java. > > Joe, Alan, please review the rest of the changes. Approved! Thanks, -Joe From Alan.Bateman at oracle.com Thu Dec 16 17:12:10 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Dec 2010 17:12:10 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D066A12.9090006@oracle.com> Message-ID: <4D0A486A.2070402@oracle.com> Neil Richards wrote: > : > I now notice that there isn't a bug in Java bug database exactly for > the problem in Hashtable - though it's obviously related to 6934356, > and to 4741471 (which removed writeObject() synchronization from the > unsynchronized collection classes). > > (As in Vector, the problem in Hashtable has existed since 1.4). > I found it: 6927486: Deadlock in legacy Hashtable writeObject() All yours :-) -Alan. From kelly.ohair at oracle.com Thu Dec 16 17:34:40 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 16 Dec 2010 09:34:40 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D09D1A3.9030308@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> Message-ID: On Dec 16, 2010, at 12:45 AM, Alan Bateman wrote: > Stuart Marks wrote: >> Hi all, >> >> As Joe Darcy mentioned yesterday [1], I'm working on updating the >> JDK libraries to use the new JDK 7 Coin features. The first feature >> is the diamond operator [2]. This first round of changes includes >> java.lang, java.io, java.sql, java.util, their corresponding tests, >> and related implementation files (exclusive of java.util.concurrent >> and related files). This change touches a total of 71 files. This >> is rather a lot of files, but the changes are all one-liners, and >> most files have only a few changes. >> >> Lance, please review the change to src/share/classes/java/sql/ >> DriverManager.java. >> >> Joe, Alan, please review the rest of the changes. >> >> For the curious, I'm using a Jackpot-based automated converter to >> make bulk changes to large numbers of source files. I plan to do >> diamond conversion of a few other groups of JDK library packages >> before moving on to other Coin features. >> >> For verification, it turns out that diamond conversion doesn't >> change the bytecodes that are emitted by the compiler, so the >> resulting class files are byte-for-byte identical to class files >> from before the change. This should make us pretty confident that >> the changes don't break anything. Unfortunately, other Coin >> features will change bytecodes, so we won't be able to use this >> easy verification technique when we apply other Coin features. >> >> The webrev is here: >> >> http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/ > Looks good to me, and very easy to review. > > One question on this. There are a couple of places where the > original statement was "too long" to fit on a single line so the RHS > of the assignment was pushed into a second line. With diamond it > means that the statement could fit on a single line. Examples are > in java.lang.Character at L649 and the changes to java.lang.Package. > It's purely a style thing but I wonder if the automated converter > can do this re-formating or whether we just leave it for future > maintenance in the respective area? But changing the line numbers will change the class file contents. :^( -kto > > -Alan. From mike.duigou at oracle.com Thu Dec 16 17:44:05 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 16 Dec 2010 09:44:05 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D095C40.4030100@oracle.com> References: <4D095C40.4030100@oracle.com> Message-ID: <88319FDE-BE90-4B69-BC55-DA7BBE149A86@oracle.com> Looks OK to me. Mike On Dec 15 2010, at 16:24 , Stuart Marks wrote: > Hi all, > > As Joe Darcy mentioned yesterday [1], I'm working on updating the JDK libraries to use the new JDK 7 Coin features. The first feature is the diamond operator [2]. This first round of changes includes java.lang, java.io, java.sql, java.util, their corresponding tests, and related implementation files (exclusive of java.util.concurrent and related files). This change touches a total of 71 files. This is rather a lot of files, but the changes are all one-liners, and most files have only a few changes. > > Lance, please review the change to src/share/classes/java/sql/DriverManager.java. > > Joe, Alan, please review the rest of the changes. > > For the curious, I'm using a Jackpot-based automated converter to make bulk changes to large numbers of source files. I plan to do diamond conversion of a few other groups of JDK library packages before moving on to other Coin features. > > For verification, it turns out that diamond conversion doesn't change the bytecodes that are emitted by the compiler, so the resulting class files are byte-for-byte identical to class files from before the change. This should make us pretty confident that the changes don't break anything. Unfortunately, other Coin features will change bytecodes, so we won't be able to use this easy verification technique when we apply other Coin features. > > The webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.0/ > > A mercurial bundle suitable for "hg unbundle" is here: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/bundle.0.hg > > Enjoy, > > s'marks > > [1] http://blogs.sun.com/darcy/entry/project_coin_minty_fresh_libraries > > [2] http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html > From Alan.Bateman at oracle.com Thu Dec 16 17:49:15 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Dec 2010 17:49:15 +0000 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> Message-ID: <4D0A511B.5050901@oracle.com> Kelly O'Hair wrote: > : > But changing the line numbers will change the class file contents. :^( True, but once this exercise moves beyond diamond then the class files will be different anyway. -Alan From joe.darcy at oracle.com Thu Dec 16 18:06:40 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Dec 2010 10:06:40 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0A511B.5050901@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> Message-ID: <4D0A5530.3050206@oracle.com> On 12/16/2010 9:49 AM, Alan Bateman wrote: > Kelly O'Hair wrote: >> : >> But changing the line numbers will change the class file contents. :^( > True, but once this exercise moves beyond diamond then the class files > will be different anyway. > And the classfiles usually differ when we change the libraries :-) -Joe From kelly.ohair at oracle.com Thu Dec 16 21:32:08 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Thu, 16 Dec 2010 21:32:08 +0000 Subject: hg: jdk7/tl/jaxp: 7007257: jaxp 1.4.5 jdk7 1st integration Message-ID: <20101216213208.2BAC44743F@hg.openjdk.java.net> Changeset: 63190d0ca619 Author: ohair Date: 2010-12-16 13:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/63190d0ca619 7007257: jaxp 1.4.5 jdk7 1st integration Reviewed-by: joehw ! jaxp.properties From kelly.ohair at oracle.com Thu Dec 16 21:40:27 2010 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Thu, 16 Dec 2010 21:40:27 +0000 Subject: hg: jdk7/tl/jaxws: 7006853: Integrate JAX-WS 2.2.2 RI into JDK 7 Message-ID: <20101216214028.084E847440@hg.openjdk.java.net> Changeset: aca101db2361 Author: ohair Date: 2010-12-16 13:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/aca101db2361 7006853: Integrate JAX-WS 2.2.2 RI into JDK 7 Reviewed-by: ramap ! jaxws.properties From gnu_andrew at member.fsf.org Fri Dec 17 01:36:29 2010 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Fri, 17 Dec 2010 01:36:29 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D066A12.9090006@oracle.com> Message-ID: On 16 December 2010 16:39, Neil Richards wrote: > On 13 December 2010 20:04, Neil Richards wrote: >> On 13 December 2010 18:46, Alan Bateman wrote: >>> I haven't looked at your patch in detail yet but I suspect there may be >>> similar issues in other places (like j.u.Hashtable) once you are done with >>> Vector. >> >> You are correct, there is a similar issue in Hashtable. >> I'm currently in the process of working up another fix and testcase >> for that, which I hope to submit separately shortly. > > I now notice that there isn't a bug in Java bug database exactly for > the problem in Hashtable - though it's obviously related to 6934356, > and to 4741471 (which removed writeObject() synchronization from the > unsynchronized collection classes). > > (As in Vector, the problem in Hashtable has existed since 1.4). > > In this case, can I raise an entry in the OpenJDK bug database for the > problem in Hashtable, or do I need to get it raised in the Java bug > database? > Commits to OpenJDK still require a bugs.sun.com ID. There was a plan nearly two years ago to actually make the OpenJDK bugzilla more useful (see http://openjdk.java.net/groups/web/bugzilla.html) but I've not heard of any progress on this. While we're still stuck with the bugs.sun.com system, It's easiest to just ask one of the Oracle developers to allocate a bug ID. They seem to be able to do so fairly instantaneously whereas it takes a lot longer externally. http://openjdk.java.net/guide/producingChangeset.html tells you how to provide an appropriate Mercurial changeset for commit. Commit comments are in a rigid format controlled by a proprietary jcheck script running on the OpenJDK servers and this will reject commit matches that don't match the format or have a duplicate bug IDs as well as patches which don't meet the whitespace formatting requirements (and probably numerous other checks that we don't know about). > Any guidance gratefully received, > Thanks, > Neil > > PS: What is the standard way of referring to a bug from one system or > the other? Or are the bug numbers from each system sufficiently far > apart to avoid ambiguity that way? > > -- > Unless stated above: > Work email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA? 7927 142C 2591 94EF D9D8 From stuart.marks at oracle.com Fri Dec 17 03:14:33 2010 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 16 Dec 2010 19:14:33 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0A5530.3050206@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> Message-ID: <4D0AD599.6040206@oracle.com> Thanks for the comments, folks. I've been puzzling over the issue of joining lines after diamond conversion if they're short enough. It turns out to be a surprisingly complex interaction of tools, code style, and process.[1] Joe and I actually talked about this issue briefly the other day and our initial inclination was not to make the additional whitespace changes. In some sense the Jackpot automated converter should do this for us, but it doesn't, and I don't want to take the time at the moment to get up to speed and modify it to do this. However, Brian and Alan and another person off-list have all raised this issue, so I think it's important that we address it. Looking at it again, leaving something like this in the code: private static Map urls = new HashMap<>(10); really offends my sensibilities, and let's face it, nobody is going to go in and fix this unless I do it now. It turns out that it isn't too difficult to write a script that can be run after-the-fact to join these lines if they end up shorter than 80 characters. Unfortunately, as Kelly points out (and I've also verified this) changing the line breaks will change the .class file contents (though not the bytecodes). The original changeset does have a very nice property of not changing the .class files at all. We could preserve this property by putting the line joins in a separate changeset. I'd do this if we could have multiple changesets with the same bugid, but a separate changeset requires a separate bugid... so maybe this isn't worth the overhead after all. I've run the line joiner and it changed ten files. Here's an incremental webrev, over and above yesterday's: http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.1/ and the corresponding hg bundle is here: http://cr.openjdk.java.net/~smarks/reviews/6880112/bundle.1.hg If this doesn't meet with any objections, I'll merge these whitespace changes and the earlier diamond conversion changes into a single changeset and then push the result. s'marks [1] "I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated." -- Poul Anderson From joe.darcy at oracle.com Fri Dec 17 03:18:39 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Dec 2010 19:18:39 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0AD599.6040206@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: <4D0AD68F.3000907@oracle.com> On 12/16/2010 7:14 PM, Stuart Marks wrote: > Thanks for the comments, folks. > > I've been puzzling over the issue of joining lines after diamond > conversion if they're short enough. It turns out to be a surprisingly > complex interaction of tools, code style, and process.[1] > > Joe and I actually talked about this issue briefly the other day and > our initial inclination was not to make the additional whitespace > changes. In some sense the Jackpot automated converter should do this > for us, but it doesn't, and I don't want to take the time at the > moment to get up to speed and modify it to do this. > > However, Brian and Alan and another person off-list have all raised > this issue, so I think it's important that we address it. Looking at > it again, leaving something like this in the code: > > private static Map urls > = new HashMap<>(10); > > really offends my sensibilities, and let's face it, nobody is going to > go in and fix this unless I do it now. It turns out that it isn't too > difficult to write a script that can be run after-the-fact to join > these lines if they end up shorter than 80 characters. > > Unfortunately, as Kelly points out (and I've also verified this) > changing the line breaks will change the .class file contents (though > not the bytecodes). The original changeset does have a very nice > property of not changing the .class files at all. We could preserve > this property by putting the line joins in a separate changeset. I'd > do this if we could have multiple changesets with the same bugid, but > a separate changeset requires a separate bugid... so maybe this isn't > worth the overhead after all. > > I've run the line joiner and it changed ten files. Here's an > incremental webrev, over and above yesterday's: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.1/ > > and the corresponding hg bundle is here: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/bundle.1.hg > > If this doesn't meet with any objections, I'll merge these whitespace > changes and the earlier diamond conversion changes into a single > changeset and then push the result. > Looks good to me - approved. -Joe From weijun.wang at oracle.com Fri Dec 17 03:50:19 2010 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Dec 2010 11:50:19 +0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0AD599.6040206@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: <4D0ADDFB.1040601@oracle.com> > > Unfortunately, as Kelly points out (and I've also verified this) > changing the line breaks will change the .class file contents (though > not the bytecodes). The original changeset does have a very nice > property of not changing the .class files at all. Maybe you can compile the codes without line number info and diff again? Max From weijun.wang at oracle.com Fri Dec 17 04:38:59 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 17 Dec 2010 04:38:59 +0000 Subject: hg: jdk7/tl/jdk: 6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to fail since jdk7 b102 Message-ID: <20101217043924.65E154746A@hg.openjdk.java.net> Changeset: 1f0f0737f04e Author: weijun Date: 2010-12-17 11:03 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f0f0737f04e 6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to fail since jdk7 b102 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/krb5/MicToken_v2.java ! src/share/classes/sun/security/jgss/krb5/WrapToken.java ! src/share/classes/sun/security/jgss/krb5/WrapToken_v2.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java - test/sun/security/krb5/auto/basic.sh From joe.darcy at oracle.com Fri Dec 17 04:43:59 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Dec 2010 20:43:59 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0ADDFB.1040601@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> <4D0ADDFB.1040601@oracle.com> Message-ID: <4D0AEA8F.7000401@oracle.com> On 12/16/2010 7:50 PM, Weijun Wang wrote: >> >> Unfortunately, as Kelly points out (and I've also verified this) >> changing the line breaks will change the .class file contents (though >> not the bytecodes). The original changeset does have a very nice >> property of not changing the .class files at all. > > Maybe you can compile the codes without line number info and diff again? I don't think that extra step is necessary given the validation that has already been done. -Joe From pbenedict at apache.org Fri Dec 17 14:54:03 2010 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 17 Dec 2010 08:54:03 -0600 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0AEA8F.7000401@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> <4D0ADDFB.1040601@oracle.com> <4D0AEA8F.7000401@oracle.com> Message-ID: Do it as two commits (one for diamond, the other for line formatting) that way you can keep the work separate. You may even want 2 Sun tracking issue in case you need to do several commits under one issue. Paul On Thu, Dec 16, 2010 at 10:43 PM, Joe Darcy wrote: > On 12/16/2010 7:50 PM, Weijun Wang wrote: >>> >>> Unfortunately, as Kelly points out (and I've also verified this) >>> changing the line breaks will change the .class file contents (though >>> not the bytecodes). The original changeset does have a very nice >>> property of not changing the .class files at all. >> >> Maybe you can compile the codes without line number info and diff again? > > I don't think that extra step is necessary given the validation that has > already been done. > > -Joe > > From stuart.marks at oracle.com Fri Dec 17 19:57:44 2010 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 17 Dec 2010 11:57:44 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> <4D0ADDFB.1040601@oracle.com> <4D0AEA8F.7000401@oracle.com> Message-ID: <4D0BC0B8.9010605@oracle.com> On 12/17/10 6:54 AM, Paul Benedict wrote: > Do it as two commits (one for diamond, the other for line formatting) > that way you can keep the work separate. You may even want 2 Sun > tracking issue in case you need to do several commits under one issue. The jcheck rules *require* a separate bug ID for each commit. I'm thinking not only of this particular change, but future changes I plan to make, where I'll do the diamond conversion other areas of the JDK, broken down into suitable chunks for easy review. It's bad enough that each chunk will require a separate bug IDs. If I were to make the diamond conversions separate changesets from line joins, it'd require *two* bug IDs for each chunk. While I agree there would be some value in keeping these changes in separate changesets, the sense I get from talking to other folks is that it isn't worth the additional overhead. s'marks From joe.darcy at oracle.com Fri Dec 17 20:06:02 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 17 Dec 2010 12:06:02 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0BC0B8.9010605@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> <4D0ADDFB.1040601@oracle.com> <4D0AEA8F.7000401@oracle.com> <4D0BC0B8.9010605@oracle.com> Message-ID: <4D0BC2AA.3070506@oracle.com> On 12/17/2010 11:57 AM, Stuart Marks wrote: > On 12/17/10 6:54 AM, Paul Benedict wrote: >> Do it as two commits (one for diamond, the other for line formatting) >> that way you can keep the work separate. You may even want 2 Sun >> tracking issue in case you need to do several commits under one issue. > > The jcheck rules *require* a separate bug ID for each commit. > > I'm thinking not only of this particular change, but future changes I > plan to make, where I'll do the diamond conversion other areas of the > JDK, broken down into suitable chunks for easy review. It's bad enough > that each chunk will require a separate bug IDs. If I were to make the > diamond conversions separate changesets from line joins, it'd require > *two* bug IDs for each chunk. > > While I agree there would be some value in keeping these changes in > separate changesets, the sense I get from talking to other folks is > that it isn't worth the additional overhead. > That is my evaluation of this situation. -Joe From kelly.ohair at oracle.com Fri Dec 17 20:37:20 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 17 Dec 2010 12:37:20 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0BC2AA.3070506@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> <4D0ADDFB.1040601@oracle.com> <4D0AEA8F.7000401@oracle.com> <4D0BC0B8.9010605@oracle.com> <4D0BC2AA.3070506@oracle.com> Message-ID: On Dec 17, 2010, at 12:06 PM, Joe Darcy wrote: > On 12/17/2010 11:57 AM, Stuart Marks wrote: >> On 12/17/10 6:54 AM, Paul Benedict wrote: >>> Do it as two commits (one for diamond, the other for line >>> formatting) >>> that way you can keep the work separate. You may even want 2 Sun >>> tracking issue in case you need to do several commits under one >>> issue. >> >> The jcheck rules *require* a separate bug ID for each commit. >> >> I'm thinking not only of this particular change, but future changes >> I plan to make, where I'll do the diamond conversion other areas of >> the JDK, broken down into suitable chunks for easy review. It's bad >> enough that each chunk will require a separate bug IDs. If I were >> to make the diamond conversions separate changesets from line >> joins, it'd require *two* bug IDs for each chunk. >> >> While I agree there would be some value in keeping these changes in >> separate changesets, the sense I get from talking to other folks is >> that it isn't worth the additional overhead. >> > > That is my evaluation of this situation. Me too. -kto > > -Joe > From mandy.chung at oracle.com Fri Dec 17 21:36:53 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Dec 2010 13:36:53 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0AD599.6040206@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: <4D0BD7F5.8050609@oracle.com> On 12/16/10 7:14 PM, Stuart Marks wrote: > > I've run the line joiner and it changed ten files. Here's an > incremental webrev, over and above yesterday's: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.1/ > Looks good to me. Mandy From mike.duigou at oracle.com Fri Dec 17 21:47:34 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 Dec 2010 13:47:34 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <4D0AD599.6040206@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: All changes look good to me. On Dec 16 2010, at 19:14 , Stuart Marks wrote: > I've run the line joiner and it changed ten files. Here's an incremental webrev, over and above yesterday's: > > http://cr.openjdk.java.net/~smarks/reviews/6880112/webrev.1/ From mike.duigou at oracle.com Sat Dec 18 00:31:35 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 17 Dec 2010 16:31:35 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() Message-ID: <84D9FDBB-E47B-43DC-903B-0FAA506E0D64@oracle.com> I've posted a webrev for review at http://cr.openjdk.java.net/~mduigou/6728865.0/webrev/ which improves the behaviour of Collections.disjoint() when the collection c1 is not a Set and is larger than c2. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728865 I've included some other micro-optimizations suggested by the issue and by common usage. One optimization, the checks whether either collection is empty using isEmpty(), may slightly degrade performance relative to the current implementation but should be a good tradeoff for cases where either of the collections are empty. I've also upgraded the javadoc to newer style conventions and included the missing @return. Any comments or feedback welcome. Mike From forax at univ-mlv.fr Sat Dec 18 01:02:32 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 18 Dec 2010 02:02:32 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() In-Reply-To: <84D9FDBB-E47B-43DC-903B-0FAA506E0D64@oracle.com> References: <84D9FDBB-E47B-43DC-903B-0FAA506E0D64@oracle.com> Message-ID: <4D0C0828.2020903@univ-mlv.fr> On 12/18/2010 01:31 AM, Mike Duigou wrote: > I've posted a webrev for review at > > http://cr.openjdk.java.net/~mduigou/6728865.0/webrev/ > > which improves the behaviour of Collections.disjoint() when the collection c1 is not a Set and is larger than c2. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728865 > > I've included some other micro-optimizations suggested by the issue and by common usage. > > One optimization, the checks whether either collection is empty using isEmpty(), may slightly degrade performance relative to the current implementation but should be a good tradeoff for cases where either of the collections are empty. > > I've also upgraded the javadoc to newer style conventions and included the missing @return. > > Any comments or feedback welcome. > > Mike Hi Mike, I think that comparing size() is not a good idea because - for some collections, size() is not a constant operation - you compare size() when c1 and c2 are sets which may cause a performance regression because disjoint(treeSet, hashSet) has not the same complexity as disjoint(hashSet, treeSet). Otherwise, you declare some local variables final. Declaring a local variable as final doesn't appear in the generated bytecode. The usual convention for the source of the JDK is to use final in front of a local variable only when needed (inner class). R?mi PS: I have also CC JSR 166 list mailing list because I know that Doug Lea also maintains patches for package java.util. From dl at cs.oswego.edu Sat Dec 18 11:13:55 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 18 Dec 2010 06:13:55 -0500 Subject: [concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() In-Reply-To: <4D0C0828.2020903@univ-mlv.fr> References: <84D9FDBB-E47B-43DC-903B-0FAA506E0D64@oracle.com> <4D0C0828.2020903@univ-mlv.fr> Message-ID: <4D0C9773.8000901@cs.oswego.edu> On 12/17/10 20:02, R?mi Forax wrote: > PS: I have also CC JSR 166 list mailing list because I know that Doug Lea also > maintains patches for package java.util. Thanks. For the set of (OpenJDK) classes that JSR166 modified but did not originate, we are content to periodically resync them. Now that OpenJDK java.util seems to be regularly maintained again, we might stop doing even this. For several years, we were the only ones ever updating them. -Doug From Ulf.Zibis at gmx.de Sat Dec 18 15:34:55 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 18 Dec 2010 16:34:55 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() In-Reply-To: <4D0C0828.2020903@univ-mlv.fr> References: <84D9FDBB-E47B-43DC-903B-0FAA506E0D64@oracle.com> <4D0C0828.2020903@univ-mlv.fr> Message-ID: <4D0CD49F.8030403@gmx.de> Am 18.12.2010 02:02, schrieb R?mi Forax: > Otherwise, you declare some local variables final. > Declaring a local variable as final doesn't appear in the generated bytecode. > The usual convention for the source of the JDK is to use final > in front of a local variable only when needed (inner class). Not always! Martin Buchholz wrote: The "final" is there purely for software engineering reasons, so that people don't make the common mistake of modifying a field cached in a local, which would have no effect. see: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003887.html -Ulf From kumar.x.srinivasan at oracle.com Sat Dec 18 17:11:14 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 18 Dec 2010 17:11:14 +0000 Subject: hg: jdk7/tl/jdk: 7007157: (pack200) stripping attributes causes a NPE Message-ID: <20101218171124.8CE9B474D0@hg.openjdk.java.net> Changeset: ae84db37130a Author: ksrini Date: 2010-12-18 09:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae84db37130a 7007157: (pack200) stripping attributes causes a NPE Reviewed-by: jrose, mduigou, dholmes ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java + test/tools/pack200/T7007157.java From kumar.x.srinivasan at oracle.com Sat Dec 18 17:39:55 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 18 Dec 2010 17:39:55 +0000 Subject: hg: jdk7/tl/langtools: 6567415: Neverending loop in ClassReader Message-ID: <20101218173957.CEC95474D2@hg.openjdk.java.net> Changeset: 3131e664558d Author: ksrini Date: 2010-12-18 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3131e664558d 6567415: Neverending loop in ClassReader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6567415/T6567415.java From mike.duigou at oracle.com Sun Dec 19 22:42:39 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 19 Dec 2010 14:42:39 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() In-Reply-To: <4D0C0828.2020903@univ-mlv.fr> References: <84D9FDBB-E47B-43DC-903B-0FAA506E0D64@oracle.com> <4D0C0828.2020903@univ-mlv.fr> Message-ID: <464CF65F-18CB-46E0-9B04-4723108AB4E1@oracle.com> On Dec 17 2010, at 17:02 , R?mi Forax wrote: > On 12/18/2010 01:31 AM, Mike Duigou wrote: >> I've posted a webrev for review at >> >> http://cr.openjdk.java.net/~mduigou/6728865.0/webrev/ >> >> which improves the behaviour of Collections.disjoint() when the collection c1 is not a Set and is larger than c2. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728865 >> >> I've included some other micro-optimizations suggested by the issue and by common usage. >> >> One optimization, the checks whether either collection is empty using isEmpty(), may slightly degrade performance relative to the current implementation but should be a good tradeoff for cases where either of the collections are empty. >> >> I've also upgraded the javadoc to newer style conventions and included the missing @return. >> >> Any comments or feedback welcome. >> >> Mike > > Hi Mike, > I think that comparing size() is not a good idea because > - for some collections, size() is not a constant operation Understood. I use isEmpty() in the case where only one of c1 and c2 is a set for this reason. > - you compare size() when c1 and c2 are sets which > may cause a performance regression because > disjoint(treeSet, hashSet) has not the same complexity as > disjoint(hashSet, treeSet). This is a good point but perhaps indicates that it might be worth adding further handling that prioritizes which collection is used for contains() The order of preference would seem to be : Collection : O(unspecified but probably no worse than N/2) Set : O(hopefully < N/2) TreeSet : O(log2 N) HashSet : O(1 + (1-loading)) There's always an issue though when c1 and c2 are of very unequal size particularly when either collection is very small. I wonder if there are cases where checking the relative size() is worth the cost. For now I will remove the size check in the case where both are Sets. > Otherwise, you declare some local variables final. > Declaring a local variable as final doesn't appear in the generated bytecode. > The usual convention for the source of the JDK is to use final > in front of a local variable only when needed (inner class). I agree it's overkill and unnecessary. I will remove it. I had put it in while checking for reassignment in an intermediate revision. Mike From mike.duigou at oracle.com Mon Dec 20 00:29:00 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 19 Dec 2010 16:29:00 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] Message-ID: I have updated the webrev for CR 6728865 with R?mi's feedback. The new webrev is at: http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ The size() comparisons are now done only when both c1 and c2 are not sets and I have removed the isEmpty() micro-optimization. Mike From Ulf.Zibis at gmx.de Mon Dec 20 04:22:03 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 20 Dec 2010 05:22:03 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: Message-ID: <4D0ED9EB.6090608@gmx.de> Hi, I think you could code shorter: Collection iterate; Collection contains; if (c2 instanceof Set) { // C2 or both are sets. iterate = c1; contains = c2; } else if (c1 instanceof Set) { // c1 is a Set, c2 is a mere Collection. iterate = c2; contains = c1; } else { // Both are mere Collections. Iterate over smaller collection. // If e.g. c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires ceiling(n/2) comparisons then // checking for all c1 elements in c2 would require 75 comparisons // vs. all c2 elements in c1 would require 100. int c1size = c1.size(); int c2size = c2.size(); if (c1size == 0 || c2size == 0) { // One of the collections is empty. Nothing will match. return true; } if (c1size < c2size) { iterate = c1; contains = c2; } else { iterate = c2; contains = c1; } } Or even more shorter: Collection iterate = c1; Collection contains = c2; if (c1 instanceof Set) { // c1 is a Set (c2 doesn't care then). iterate = c2; contains = c1; } else if (!(c2 instanceof Set)) { // Both are mere Collections. Iterate over smaller collection. // If e.g. c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires ceiling(n/2) comparisons then // checking for all c1 elements in c2 would require 75 comparisons // vs. all c2 elements in c1 would require 100. int c1size = c1.size(); int c2size = c2.size(); if (c1size == 0 || c2size == 0) { // One of the collections is empty. Nothing will match. return true; } else if (c1size > c2size) { iterate = c2; contains = c1; } } Minor nits: - correct indentation to multiples of 4 - insert space after "if" - start comment phrases with capital letter, if ending with "." - add "e.g." to comment -Ulf Am 20.12.2010 01:29, schrieb Mike Duigou: > I have updated the webrev for CR 6728865 with R?mi's feedback. The new webrev is at: > > http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ > > The size() comparisons are now done only when both c1 and c2 are not sets and I have removed the isEmpty() micro-optimization. > > Mike From David.Holmes at oracle.com Mon Dec 20 00:42:05 2010 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 20 Dec 2010 10:42:05 +1000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: Message-ID: <4D0EA65D.5090101@oracle.com> Hi Mike, Mike Duigou said the following on 12/20/10 10:29: > I have updated the webrev for CR 6728865 with R?mi's feedback. The new webrev is at: > > http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ > > The size() comparisons are now done only when both c1 and c2 are not sets and I have removed the isEmpty() micro-optimization. So to summarise this change: 1. The original code checked for c1 being a set and not c2, but not vice-versa - this fixes that 2. This code adds an optimization when they are both not sets but at least one is empty Did I miss anything? Seems functionally sound to me, but I can't attest to any performance benefits. Cheers, David Holmes From stuart.marks at oracle.com Mon Dec 20 21:48:54 2010 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Mon, 20 Dec 2010 21:48:54 +0000 Subject: hg: jdk7/tl/jdk: 6880112: Project Coin: Port JDK core library code to use diamond operator Message-ID: <20101220214903.BEE164754A@hg.openjdk.java.net> Changeset: 449dfb061fde Author: smarks Date: 2010-12-20 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/449dfb061fde 6880112: Project Coin: Port JDK core library code to use diamond operator Reviewed-by: darcy, lancea, alanb, briangoetz, mduigou, mchung ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimSort.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/io/Serializable/NPEProvoker/NPEProvoker.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/lang/instrument/ilib/InjectBytecodes.java ! test/java/lang/reflect/Generics/TestPlainArrayNotGeneric.java ! test/java/util/Random/DistinctSeeds.java ! test/java/util/logging/ClassLoaderLeakTest.java From pbenedict at apache.org Mon Dec 20 22:20:59 2010 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 20 Dec 2010 16:20:59 -0600 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: I once heard/read that Sun had a policy where JDK N had to built with the JDK N-1 compiler. I suppose that's not true anymore? From kelly.ohair at oracle.com Mon Dec 20 22:43:21 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 20 Dec 2010 14:43:21 -0800 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: <30FCB208-7E57-4BF1-A336-FA77DB3824B5@oracle.com> Not sure about a policy, but yes typically we require the previous JDK release to be the "boot" jdk. However, the policy, if you want to call it that, has relaxed a bit, it does need to be a previously released jdk. We require a jdk6u14 or newer for jdk7, and I suspect the newer jdk6 update releases also require jdk6u14 or newer as a 'boot' jdk. The jdk7 javac compiler (langtools repository) needs to build and run with the 'boot' jdk. There are other sets of Java sources in jdk7 that may also need to be jdk6-ish, like the jax* sources. -kto On Dec 20, 2010, at 2:20 PM, Paul Benedict wrote: > I once heard/read that Sun had a policy where JDK N had to built with > the JDK N-1 compiler. I suppose that's not true anymore? From mike.duigou at oracle.com Tue Dec 21 01:48:45 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 20 Dec 2010 17:48:45 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D0EA65D.5090101@oracle.com> References: <4D0EA65D.5090101@oracle.com> Message-ID: <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> I've updated the webrev with Ulf's feedback. http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/ The old heuristics: 1. If c1 is a Set then iterate over c2. 2. Iterate over the smaller Collection. I believe that the || in the original should have been a && I've rearranged it as branches in my revision. The new heuristics: 1. If c1 is a Set then iterate over c2. 2. If c2 is a Set then iterate over c1. 3. If either collection is empty then result is always true. 4. Iterate over the smaller Collection. Mike On Dec 19 2010, at 16:42 , David Holmes wrote: > Hi Mike, > > Mike Duigou said the following on 12/20/10 10:29: >> I have updated the webrev for CR 6728865 with R?mi's feedback. The new webrev is at: >> http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ >> The size() comparisons are now done only when both c1 and c2 are not sets and I have removed the isEmpty() micro-optimization. > > So to summarise this change: > > 1. The original code checked for c1 being a set and not c2, but not vice-versa - this fixes that > > 2. This code adds an optimization when they are both not sets but at least one is empty > > Did I miss anything? > > Seems functionally sound to me, but I can't attest to any performance benefits. > > Cheers, > David Holmes From David.Holmes at oracle.com Tue Dec 21 02:24:49 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 21 Dec 2010 12:24:49 +1000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> Message-ID: <4D100FF1.6060702@oracle.com> Functionality looks okay to me. I think those spec/doc clarifications may need to go through CCC though. David Mike Duigou said the following on 12/21/10 11:48: > I've updated the webrev with Ulf's feedback. http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/ > > The old heuristics: > > 1. If c1 is a Set then iterate over c2. > > 2. Iterate over the smaller Collection. > > > I believe that the || in the original should have been a && > > I've rearranged it as branches in my revision. > > > The new heuristics: > > 1. If c1 is a Set then iterate over c2. > > 2. If c2 is a Set then iterate over c1. > > 3. If either collection is empty then result is always true. > > 4. Iterate over the smaller Collection. > > Mike > > > > On Dec 19 2010, at 16:42 , David Holmes wrote: > >> Hi Mike, >> >> Mike Duigou said the following on 12/20/10 10:29: >>> I have updated the webrev for CR 6728865 with R?mi's feedback. The new webrev is at: >>> http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ >>> The size() comparisons are now done only when both c1 and c2 are not sets and I have removed the isEmpty() micro-optimization. >> So to summarise this change: >> >> 1. The original code checked for c1 being a set and not c2, but not vice-versa - this fixes that >> >> 2. This code adds an optimization when they are both not sets but at least one is empty >> >> Did I miss anything? >> >> Seems functionally sound to me, but I can't attest to any performance benefits. >> >> Cheers, >> David Holmes > From forax at univ-mlv.fr Tue Dec 21 08:10:41 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 21 Dec 2010 09:10:41 +0100 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: <30FCB208-7E57-4BF1-A336-FA77DB3824B5@oracle.com> References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> <30FCB208-7E57-4BF1-A336-FA77DB3824B5@oracle.com> Message-ID: <4D106101.5010101@univ-mlv.fr> Paul, see http://blogs.sun.com/jjg/entry/building_javac_for_jdk7 If you want more details. R?mi On 12/20/2010 11:43 PM, Kelly O'Hair wrote: > Not sure about a policy, but yes typically we require the previous JDK > release to be > the "boot" jdk. However, the policy, if you want to call it that, has > relaxed a bit, it does > need to be a previously released jdk. > > We require a jdk6u14 or newer for jdk7, and I suspect the newer jdk6 > update releases > also require jdk6u14 or newer as a 'boot' jdk. > > The jdk7 javac compiler (langtools repository) needs to build and run > with the 'boot' jdk. > There are other sets of Java sources in jdk7 that may also need to be > jdk6-ish, like the jax* > sources. > > -kto > > On Dec 20, 2010, at 2:20 PM, Paul Benedict wrote: > >> I once heard/read that Sun had a policy where JDK N had to built with >> the JDK N-1 compiler. I suppose that's not true anymore? > From weijun.wang at oracle.com Tue Dec 21 09:36:23 2010 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 21 Dec 2010 09:36:23 +0000 Subject: hg: jdk7/tl/jdk: 6996367: improve HandshakeHash Message-ID: <20101221093633.0552747571@hg.openjdk.java.net> Changeset: d2a0e795c1c2 Author: weijun Date: 2010-12-21 17:35 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d2a0e795c1c2 6996367: improve HandshakeHash Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java From chris.hegarty at oracle.com Tue Dec 21 10:43:47 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 21 Dec 2010 10:43:47 +0000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D100FF1.6060702@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> Message-ID: <4D1084E3.9050504@oracle.com> On 12/21/10 02:24 AM, David Holmes wrote: > Functionality looks okay to me. > > I think those spec/doc clarifications may need to go through CCC though. I agree with David, a CCC request should be filed for the spec changes. We should agree the spec changes on this mailing list before proposing them. I understand where you're coming from with this spec change, but I think the additional text may be too restricting. "@throws NullPointerException ......... or if one collection contains {@code null} and the other collection does not permit {@code null} values." For example, the following would be required to throw NPE ( but I don't believe your impl does): Set set = new HashSet(); set.add(null); PriorityQueue pq = new PriorityQueue(); Collections.disjoint(set, pq); I think we may have to be a little more relaxed here, maybe just a cautionary note, "it may happen"??? -Chris. > > David > > Mike Duigou said the following on 12/21/10 11:48: >> I've updated the webrev with Ulf's feedback. >> http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/ >> >> The old heuristics: >> >> 1. If c1 is a Set then iterate over c2. >> >> 2. Iterate over the smaller Collection. >> >> >> I believe that the || in the original should have been a && >> >> I've rearranged it as branches in my revision. >> >> >> The new heuristics: >> >> 1. If c1 is a Set then iterate over c2. >> >> 2. If c2 is a Set then iterate over c1. >> >> 3. If either collection is empty then result is always true. >> >> 4. Iterate over the smaller Collection. >> >> Mike >> >> >> >> On Dec 19 2010, at 16:42 , David Holmes wrote: >> >>> Hi Mike, >>> >>> Mike Duigou said the following on 12/20/10 10:29: >>>> I have updated the webrev for CR 6728865 with R?mi's feedback. The >>>> new webrev is at: >>>> http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ >>>> The size() comparisons are now done only when both c1 and c2 are not >>>> sets and I have removed the isEmpty() micro-optimization. >>> So to summarise this change: >>> >>> 1. The original code checked for c1 being a set and not c2, but not >>> vice-versa - this fixes that >>> >>> 2. This code adds an optimization when they are both not sets but at >>> least one is empty >>> >>> Did I miss anything? >>> >>> Seems functionally sound to me, but I can't attest to any performance >>> benefits. >>> >>> Cheers, >>> David Holmes >> From Ulf.Zibis at gmx.de Tue Dec 21 13:44:08 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 21 Dec 2010 14:44:08 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> Message-ID: <4D10AF28.3080303@gmx.de> Am 21.12.2010 02:48, schrieb Mike Duigou: > I've updated the webrev with Ulf's feedback. http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/ I think your explanation belongs to both variables, contains and iterate. Furthermore the iterated collection is the one with the major importance and accessed first, so declare and later assign it at 1. position: // As performance of Set's contains() is less than O(N/2), // iteration is given to the remaining collection. // For collections who's contains() are of the same complexity then // best performance is achieved by iterating the smaller collection. Collection iterate; Collection contains; But anyway, the explanation IMO would be better located close to the if...else branch (see for my 2nd approach below). Better concatenate else + if into one line, so the first 3 cases of your heuristics appear more clear: } else if (c2 instanceof Set) { Now "E.g." should be capitalized instead "if". ;-) Anyway I still prefer my 2nd approach, as it's more compact and easier to follow. I believe, GIT compiler will optimize the actual order of operations anyway, and javac maybe too. But my code could be better documented: // collections to iterate and compare on Collection iterate = c1; Collection contains = c2; // performance optimization cases if (c1 instanceof Set) { // As Set's contains() performs better (less than O(N/2)) //than mere Collection's,iterate on c2. iterate = c2; contains = c1; } else if (!(c2 instanceof Set)) { // Both are mere Collections. Iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires ceiling(n/2) comparisons then // checking for all c1 elements in c2 would require 75 comparisons // vs. all c2 elements in c1 would require 100. int c1size = c1.size(); int c2size = c2.size(); if (c1size == 0 || c2size == 0) { // One of the collections is empty. Nothing will match. return true; } else if (c1size > c2size) { iterate = c2; contains = c1; } } The heuristics: 1. Generally iterate over c1. 2. If c1 is a Set then iterate over c2. 3. If either collection is empty then result is always true. 4. Iterate over the smaller Collection. -Ulf From Ulf.Zibis at gmx.de Tue Dec 21 14:01:41 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 21 Dec 2010 15:01:41 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D10AF28.3080303@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D10AF28.3080303@gmx.de> Message-ID: <4D10B345.2010201@gmx.de> Am 21.12.2010 14:44, schrieb Ulf Zibis: > > // As performance of Set's contains() is less than O(N/2), > // iteration is given to the remaining collection. > // For collections who's contains() are of the same complexity then > // best performance is achieved by iterating the smaller collection. > Collection iterate; > Collection contains; Maybe better readable: // As mere Collection's contains() likely performs worse than // Set's, less than O(N/2), iterate on alternative/remaining collection. > ... 2nd approach: if (c1 instanceof Set) { // As mere Collection's contains() likely performs worse than // Set's, less than O(N/2), iterate on c2. -Ulf From Ulf.Zibis at gmx.de Tue Dec 21 14:14:16 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 21 Dec 2010 15:14:16 +0100 Subject: code review request for 6880112, Coin: use diamond in core libraries In-Reply-To: References: <4D095C40.4030100@oracle.com> <4D09D1A3.9030308@oracle.com> <4D0A511B.5050901@oracle.com> <4D0A5530.3050206@oracle.com> <4D0AD599.6040206@oracle.com> Message-ID: <4D10B638.7030808@gmx.de> If you were right, we never would have had generic code in 1.5 libraries. :-) -Ulf Am 20.12.2010 23:20, schrieb Paul Benedict: > I once heard/read that Sun had a policy where JDK N had to built with > the JDK N-1 compiler. I suppose that's not true anymore? > From mike.duigou at oracle.com Tue Dec 21 19:35:41 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 Dec 2010 11:35:41 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1084E3.9050504@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> Message-ID: <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> On Dec 21 2010, at 02:43 , Chris Hegarty wrote: > On 12/21/10 02:24 AM, David Holmes wrote: >> Functionality looks okay to me. >> >> I think those spec/doc clarifications may need to go through CCC though. > > I agree with David, a CCC request should be filed for the spec changes. We should agree the spec changes on this mailing list before proposing them. > > I understand where you're coming from with this spec change, but I think the additional text may be too restricting. > > "@throws NullPointerException ......... or if one collection > contains {@code null} and the other collection does not permit > {@code null} values." > > For example, the following would be required to throw NPE ( but I don't believe your impl does): > > Set set = new HashSet(); > set.add(null); > PriorityQueue pq = new PriorityQueue(); > Collections.disjoint(set, pq); > > I think we may have to be a little more relaxed here, maybe just a cautionary note, "it may happen"??? You are correct that it's not guaranteed that NPE will be thrown. Here's the amended text for the main javadoc: *

Care must also be exercised when using a mix of collections that * permit {@code null} values and those that do not. If either * collection does not permit {@code null} values then {@code null} must * not be a value in either collection. * and this is the revised @throw NullPointerException: * @throws NullPointerException if either collection is {@code null}. May * also be thrown if one collection contains a {@code null} value and the * other collection does not permit {@code null} values. Note that the descriptive paragraph says "must not" because we don't commit to which collection is used for contains() and the @throw says "may" because, per your example, if the collection not permitting null is used for iteration then NPE will not be thrown. Mike > -Chris. > >> >> David >> >> Mike Duigou said the following on 12/21/10 11:48: >>> I've updated the webrev with Ulf's feedback. >>> http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/ >>> >>> The old heuristics: >>> >>> 1. If c1 is a Set then iterate over c2. >>> >>> 2. Iterate over the smaller Collection. >>> >>> >>> I believe that the || in the original should have been a && >>> >>> I've rearranged it as branches in my revision. >>> >>> >>> The new heuristics: >>> >>> 1. If c1 is a Set then iterate over c2. >>> >>> 2. If c2 is a Set then iterate over c1. >>> >>> 3. If either collection is empty then result is always true. >>> >>> 4. Iterate over the smaller Collection. >>> >>> Mike >>> >>> >>> >>> On Dec 19 2010, at 16:42 , David Holmes wrote: >>> >>>> Hi Mike, >>>> >>>> Mike Duigou said the following on 12/20/10 10:29: >>>>> I have updated the webrev for CR 6728865 with R?mi's feedback. The >>>>> new webrev is at: >>>>> http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ >>>>> The size() comparisons are now done only when both c1 and c2 are not >>>>> sets and I have removed the isEmpty() micro-optimization. >>>> So to summarise this change: >>>> >>>> 1. The original code checked for c1 being a set and not c2, but not >>>> vice-versa - this fixes that >>>> >>>> 2. This code adds an optimization when they are both not sets but at >>>> least one is empty >>>> >>>> Did I miss anything? >>>> >>>> Seems functionally sound to me, but I can't attest to any performance >>>> benefits. >>>> >>>> Cheers, >>>> David Holmes >>> From eamonn.mcmanus at oracle.com Tue Dec 21 21:15:27 2010 From: eamonn.mcmanus at oracle.com (Eamonn McManus) Date: Tue, 21 Dec 2010 22:15:27 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> Message-ID: <4D1118EF.1080300@oracle.com> I think that is still not quite right. The spec for Collection says that a Collection that does not support adding null values may or may not support looking them up. So in both places where you say "does not permit null values" I think you should probably say "does not permit looking up null values". ?amonn On 21/12/2010 20:35, Mike Duigou wrote: > On Dec 21 2010, at 02:43 , Chris Hegarty wrote: > >> On 12/21/10 02:24 AM, David Holmes wrote: >>> Functionality looks okay to me. >>> >>> I think those spec/doc clarifications may need to go through CCC though. >> I agree with David, a CCC request should be filed for the spec changes. We should agree the spec changes on this mailing list before proposing them. >> >> I understand where you're coming from with this spec change, but I think the additional text may be too restricting. >> >> "@throws NullPointerException ......... or if one collection >> contains {@code null} and the other collection does not permit >> {@code null} values." >> >> For example, the following would be required to throw NPE ( but I don't believe your impl does): >> >> Set set = new HashSet(); >> set.add(null); >> PriorityQueue pq = new PriorityQueue(); >> Collections.disjoint(set, pq); >> >> I think we may have to be a little more relaxed here, maybe just a cautionary note, "it may happen"??? > You are correct that it's not guaranteed that NPE will be thrown. Here's the amended text for the main javadoc: > > *

Care must also be exercised when using a mix of collections that > * permit {@code null} values and those that do not. If either > * collection does not permit {@code null} values then {@code null} must > * not be a value in either collection. > * > > and this is the revised @throw NullPointerException: > > * @throws NullPointerException if either collection is {@code null}. May > * also be thrown if one collection contains a {@code null} value and the > * other collection does not permit {@code null} values. > > > Note that the descriptive paragraph says "must not" because we don't commit to which collection is used for contains() and the @throw says "may" because, per your example, if the collection not permitting null is used for iteration then NPE will not be thrown. > > Mike > >> -Chris. >> >>> David >>> >>> Mike Duigou said the following on 12/21/10 11:48: >>>> I've updated the webrev with Ulf's feedback. >>>> http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/ >>>> >>>> The old heuristics: >>>> >>>> 1. If c1 is a Set then iterate over c2. >>>> >>>> 2. Iterate over the smaller Collection. >>>> >>>> >>>> I believe that the || in the original should have been a&& >>>> >>>> I've rearranged it as branches in my revision. >>>> >>>> >>>> The new heuristics: >>>> >>>> 1. If c1 is a Set then iterate over c2. >>>> >>>> 2. If c2 is a Set then iterate over c1. >>>> >>>> 3. If either collection is empty then result is always true. >>>> >>>> 4. Iterate over the smaller Collection. >>>> >>>> Mike >>>> >>>> >>>> >>>> On Dec 19 2010, at 16:42 , David Holmes wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> Mike Duigou said the following on 12/20/10 10:29: >>>>>> I have updated the webrev for CR 6728865 with R?mi's feedback. The >>>>>> new webrev is at: >>>>>> http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/ >>>>>> The size() comparisons are now done only when both c1 and c2 are not >>>>>> sets and I have removed the isEmpty() micro-optimization. >>>>> So to summarise this change: >>>>> >>>>> 1. The original code checked for c1 being a set and not c2, but not >>>>> vice-versa - this fixes that >>>>> >>>>> 2. This code adds an optimization when they are both not sets but at >>>>> least one is empty >>>>> >>>>> Did I miss anything? >>>>> >>>>> Seems functionally sound to me, but I can't attest to any performance >>>>> benefits. >>>>> >>>>> Cheers, >>>>> David Holmes From mike.duigou at oracle.com Tue Dec 21 21:38:27 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 Dec 2010 13:38:27 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1118EF.1080300@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> Message-ID: Thanks. That's an important clarification to include. Here's the revised text: * *

Care must also be exercised when using collections that do not permit * calling the {@code contains} method with a {@code null} value. If either * collection does not permit {@code contains(null)} then both collections * must not contain {@code null} values. * and the @throws text: * @throws NullPointerException if either collection is {@code null}. May * also be thrown if one collection contains a {@code null} value and the * other collection does not permit {@code contains(null)}. Mike On Dec 21 2010, at 13:15 , Eamonn McManus wrote: > I think that is still not quite right. The spec for Collection says that a Collection that does not support adding null values may or may not support looking them up. So in both places where you say "does not permit null values" I think you should probably say "does not permit looking up null values". > > ?amonn > > On 21/12/2010 20:35, Mike Duigou wrote: >> On Dec 21 2010, at 02:43 , Chris Hegarty wrote: >> >>> On 12/21/10 02:24 AM, David Holmes wrote: >>>> Functionality looks okay to me. >>>> >>>> I think those spec/doc clarifications may need to go through CCC though. >>> I agree with David, a CCC request should be filed for the spec changes. We should agree the spec changes on this mailing list before proposing them. >>> >>> I understand where you're coming from with this spec change, but I think the additional text may be too restricting. >>> >>> "@throws NullPointerException ......... or if one collection >>> contains {@code null} and the other collection does not permit >>> {@code null} values." >>> >>> For example, the following would be required to throw NPE ( but I don't believe your impl does): >>> >>> Set set = new HashSet(); >>> set.add(null); >>> PriorityQueue pq = new PriorityQueue(); >>> Collections.disjoint(set, pq); >>> >>> I think we may have to be a little more relaxed here, maybe just a cautionary note, "it may happen"??? >> You are correct that it's not guaranteed that NPE will be thrown. Here's the amended text for the main javadoc: >> >> *

Care must also be exercised when using a mix of collections that >> * permit {@code null} values and those that do not. If either >> * collection does not permit {@code null} values then {@code null} must >> * not be a value in either collection. >> * >> >> and this is the revised @throw NullPointerException: >> >> * @throws NullPointerException if either collection is {@code null}. May >> * also be thrown if one collection contains a {@code null} value and the >> * other collection does not permit {@code null} values. >> >> >> Note that the descriptive paragraph says "must not" because we don't commit to which collection is used for contains() and the @throw says "may" because, per your example, if the collection not permitting null is used for iteration then NPE will not be thrown. >> >> Mike >> From lnarasimhan at in.ibm.com Tue Dec 21 22:34:54 2010 From: lnarasimhan at in.ibm.com (Lakshmi Narasimhan) Date: Wed, 22 Dec 2010 04:04:54 +0530 Subject: AUTO: Lakshmi Narasimhan is on leave (returning 29/12/2010) Message-ID: I am out of the office until 29/12/2010. Please contact Amar Devegowda (adevegow at in.ibm.com) for any queries on Class Libraries. For anything else, please contact my manager Arvind Ramakrishnan (arvindr at in.ibm.com) Note: This is an automated response to your message "core-libs-dev Digest, Vol 44, Issue 31" sent on 22/12/10 1:30:00. This is the only notification you will receive while this person is away. From kevin.walls at oracle.com Tue Dec 21 22:39:51 2010 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Tue, 21 Dec 2010 22:39:51 +0000 Subject: hg: jdk7/tl/jdk: 6968933: Clip loop() deadlock in DirectAudioDevice$DirectClip.run Message-ID: <20101221224001.5E6DA4759C@hg.openjdk.java.net> Changeset: d36ad8686f6d Author: kevinw Date: 2010-12-21 11:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d36ad8686f6d 6968933: Clip loop() deadlock in DirectAudioDevice$DirectClip.run Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java From neil.richards at ngmr.net Tue Dec 21 23:06:37 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 21 Dec 2010 23:06:37 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> Message-ID: On 16 December 2010 16:24, Neil Richards wrote: > On 16 December 2010 13:01, Alan Bateman wrote: >> On the test case, it needs the GPL header. There are templates in the >> repository and you'll also see tests contributed by RedHat and Google if >> that helps. > > Ah, sorry. I'll work on getting the right words in there, and will > attach a modified changeset as soon as I have it sorted. > >> Another thing to mention is that hard-coded timeouts are >> problematic. In this case a 1s timeout might not be sufficient when on a >> machine that is running many tests concurrently. One suggestion is to just >> leave the threads deadlock and the test will timeout and fail if the bug >> exists. > > So I'm happy to modify the test if the jtreg test harness deals with > cleaning up hanging tests, reporting them as failures. As trailed, please find attached a modified changeset, eliminating the timeout from the testcase, and adding an appropriate header. I've also added a second testcase, which demonstrates that Vector serialization still works with the fix. Please review this modified changeset, and let me know if anything further is required for its acceptance. Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: 6934356.export Type: application/octet-stream Size: 11085 bytes Desc: not available URL: From jim.holmlund at sun.com Wed Dec 22 00:33:07 2010 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 22 Dec 2010 00:33:07 +0000 Subject: hg: jdk7/tl/langtools: 7008378: javac bootstrap launcher fails on cygwin when called via an absolute path Message-ID: <20101222003309.C9693475A3@hg.openjdk.java.net> Changeset: 7c33098600b2 Author: jjh Date: 2010-12-21 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c33098600b2 7008378: javac bootstrap launcher fails on cygwin when called via an absolute path Summary: Use cygpath if it is cygwin Reviewed-by: ksrini ! make/Makefile ! make/build.xml ! src/share/bin/launcher.sh-template From neil.richards at ngmr.net Wed Dec 22 01:08:27 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 22 Dec 2010 01:08:27 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() Message-ID: Please find attached a changeset to address the problem reported in bug 6927486, "Deadlock in legacy Hashtable writeObject()". The problem reported is similar to one found in java.util.Vector, for which a fix is also currently under review (http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005529.html). This fixes approach is similar to that in Vector - namely to record the objects to be serialized within the synchronization in Hashtable.writeObject(), so that the calls to writeObject() in that method can be moved to beyond the synchronization, thus avoiding the possibility of deadlock. (The calls to writeObject() - for the keys and value of the hashtable's entries - are the last activity within Hashtable.writeObject(), so no additional calls need be delayed). The keys and values to be written out are recorded in a stack of Entry objects, created specially for the task to form a local single-linked list of entries, which is then traversed outside the synchronized block to make the calls to s.writeObject() with each entry's key and value. I believe this is the most efficient means of addressing the problem - any suggestions on how to further improve it gratefully received. As the order of writing out the entries has effectively changed from FIFO to LIFO (as it uses a stack), I have reversed the order the code traverses the table (from low index to high). (I note that the API doc explicitly gives no guarantees as to the order the entries are serialized. Nevertheless, as the initial traversal order was the more uncommon of the two forms, I suspect that there might be some deeper reasoning as to why it was done that way, hence why I've tried to retain its spirit). Any reviews or comment gratefully received, Thanks, Neil PS: The evaluation of this bug suggests that java.util.Random and java.util.PropertyPermission may also be susceptible to serialization deadlock (ie. in addition to Vector and Hashtable). I do not believe this to be case: whilst their writeObject() methods are synchronized, neither class needs to call ObjectOutputStream.writeObject() within them, so the possibility of deadlock there cannot arise. PPS: I notice the API javadoc for PropertyPermission does not give its serialized form (and the "See Also:" section), even though it is Serializable, which strikes me as unusual. I suppose it has no serializable fields of its own (over that which BasicPermission has), but I'm sure I've seen other serializable classes with no fields having "serialized form" entries. -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: 6927486.export Type: application/octet-stream Size: 12106 bytes Desc: not available URL: From neil.richards at ngmr.net Wed Dec 22 11:19:36 2010 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 22 Dec 2010 11:19:36 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: <4D11C701.70501@oracle.com> References: <4D11C701.70501@oracle.com> Message-ID: On 22 December 2010 09:38, David Holmes wrote: > Hi Neil, > > Any chance you can generate webrevs as mentioned in: > > http://openjdk.java.net/guide/changePlanning.html Hi David, >From the documentation, I don't believe I can do so yet. http://cr.openjdk.java.net/ (referred to from the page you mention) says: "Any user with push access to the OpenJDK Mercurial server can publish materials on this server." As I don't think I have yet been granted push access to the OpenJDK Mercurial server, I'm not in a position to publish webrevs for review. I've tried to follow the documented process - as best as I can figure out (!) - from http://openjdk.java.net/contribute/ and http://openjdk.java.net/guide/producingChangeset.html Please let me know if there's anything else (within my power) I can do to aid the review process. Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From dalibor.topic at Oracle.com Wed Dec 22 12:47:16 2010 From: dalibor.topic at Oracle.com (Dalibor Topic) Date: Wed, 22 Dec 2010 13:47:16 +0100 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: <4D11C701.70501@oracle.com> Message-ID: <4D11F354.2070402@oracle.com> On 12/22/10 12:19 PM, Neil Richards wrote: > On 22 December 2010 09:38, David Holmes wrote: >> Hi Neil, >> >> Any chance you can generate webrevs as mentioned in: >> >> http://openjdk.java.net/guide/changePlanning.html > > Hi David, >>From the documentation, I don't believe I can do so yet. > Hi Neil, As a workaround, if you fetch the webrev script from http://blogs.sun.com/jcc/resource/webrev and run it on your hg tree, it will generate a webrev.zip file, along with a webrev, which you can send to this list as an attachment until you get an account on cr.openjdk. For an introduction to webrev, please see http://blogs.sun.com/jcc/entry/webrev_for_openjdk_a_code cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From ptisnovs at redhat.com Wed Dec 22 13:34:44 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Wed, 22 Dec 2010 13:34:44 +0000 Subject: hg: jdk7/tl/jdk: 6560348: PIT : java/awt/xembed/server/RunTestXEmbed.java fails Message-ID: <20101222133501.3349747629@hg.openjdk.java.net> Changeset: 9deace8396f9 Author: ptisnovs Date: 2010-12-22 14:37 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9deace8396f9 6560348: PIT : java/awt/xembed/server/RunTestXEmbed.java fails Summary: Testcase correction. Reviewed-by: anthony ! test/java/awt/xembed/server/TestXEmbedServer.java From chris.hegarty at oracle.com Wed Dec 22 13:45:02 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Dec 2010 13:45:02 +0000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> Message-ID: <4D1200DE.3040107@oracle.com> Mike, On 12/21/10 09:38 PM, Mike Duigou wrote: > Thanks. That's an important clarification to include. Here's the revised text: > > * > *

Care must also be exercised when using collections that do not permit > * calling the {@code contains} method with a {@code null} value. If either > * collection does not permit {@code contains(null)} then both collections > * must not contain {@code null} values. > * > > and the @throws text: > > * @throws NullPointerException if either collection is {@code null}. May > * also be thrown if one collection contains a {@code null} value and the > * other collection does not permit {@code contains(null)}. My concern with this revised wording is that you are now specifying that the implementation must use contains() ( and not be implemented using a different strategy ). I guess an alternative implementation is unlikely, but this does appear overly restricting. I wonder if its really necessary to add text to the NPE. A cautionary note may be sufficient. We could also throw ClassCastException, but there is no mention of it in the spec. Sorry for being a pain about this, I'm just concerned with adding overly restricting spec. Have we thought about catching/swallowing these exceptions? -Chris. > > Mike > > On Dec 21 2010, at 13:15 , Eamonn McManus wrote: > >> I think that is still not quite right. The spec for Collection says that a Collection that does not support adding null values may or may not support looking them up. So in both places where you say "does not permit null values" I think you should probably say "does not permit looking up null values". >> >> ?amonn >> >> On 21/12/2010 20:35, Mike Duigou wrote: >>> On Dec 21 2010, at 02:43 , Chris Hegarty wrote: >>> >>>> On 12/21/10 02:24 AM, David Holmes wrote: >>>>> Functionality looks okay to me. >>>>> >>>>> I think those spec/doc clarifications may need to go through CCC though. >>>> I agree with David, a CCC request should be filed for the spec changes. We should agree the spec changes on this mailing list before proposing them. >>>> >>>> I understand where you're coming from with this spec change, but I think the additional text may be too restricting. >>>> >>>> "@throws NullPointerException ......... or if one collection >>>> contains {@code null} and the other collection does not permit >>>> {@code null} values." >>>> >>>> For example, the following would be required to throw NPE ( but I don't believe your impl does): >>>> >>>> Set set = new HashSet(); >>>> set.add(null); >>>> PriorityQueue pq = new PriorityQueue(); >>>> Collections.disjoint(set, pq); >>>> >>>> I think we may have to be a little more relaxed here, maybe just a cautionary note, "it may happen"??? >>> You are correct that it's not guaranteed that NPE will be thrown. Here's the amended text for the main javadoc: >>> >>> *

Care must also be exercised when using a mix of collections that >>> * permit {@code null} values and those that do not. If either >>> * collection does not permit {@code null} values then {@code null} must >>> * not be a value in either collection. >>> * >>> >>> and this is the revised @throw NullPointerException: >>> >>> * @throws NullPointerException if either collection is {@code null}. May >>> * also be thrown if one collection contains a {@code null} value and the >>> * other collection does not permit {@code null} values. >>> >>> >>> Note that the descriptive paragraph says "must not" because we don't commit to which collection is used for contains() and the @throw says "may" because, per your example, if the collection not permitting null is used for iteration then NPE will not be thrown. >>> >>> Mike >>> > From xuelei.fan at oracle.com Wed Dec 22 14:29:42 2010 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 22 Dec 2010 14:29:42 +0000 Subject: hg: jdk7/tl/jdk: 6996365: Evaluate the priorities of cipher suites Message-ID: <20101222142952.220804762C@hg.openjdk.java.net> Changeset: 0d826185a92e Author: xuelei Date: 2010-12-22 06:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0d826185a92e 6996365: Evaluate the priorities of cipher suites Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java From roman.kennke at jpmchase.com Wed Dec 22 14:36:06 2010 From: roman.kennke at jpmchase.com (Roman Kennke) Date: Wed, 22 Dec 2010 15:36:06 +0100 Subject: Potential memory leak in java.util.logging.Level Message-ID: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> Hello, I believe java.util.logging.Level is potentially memory leaking. This can happen if an application defines its own subclass of Level and is loaded by its own classloader. Level's constructor adds a reference to the new instance of the subclass to its 'known' ArrayList (which is a static field). This instance is never removed from that list. And since this instance holds a reference to its classloader, this means that no classes loaded by that classloader can be unloaded. It could be argued that you should not do crazy stuff with classloaders, but this happens invariably when you deal with applets. I guess similar problems can arise on app servers as well. I wonder why Level's constructors need to be protected though. If they were public, and new Levels could be created simply by instantiating one, this whole problem would not exist. Then the Level.known list would only reference instances of its own class, which would be problematic, unless you create LOTS of levels, which is unlikely. I don't like static collection fields anyway... too prone to leaking. Is this a known problem? Is there a solution to this, except not creating custom log levels? How else could custom log levels be created under those circumstances that would not trigger this problem? Thanks, Roman This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. From forax at univ-mlv.fr Wed Dec 22 15:07:41 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 22 Dec 2010 16:07:41 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1200DE.3040107@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> Message-ID: <4D12143D.5030702@univ-mlv.fr> Hi Chris, On 12/22/2010 02:45 PM, Chris Hegarty wrote: > Mike, > > On 12/21/10 09:38 PM, Mike Duigou wrote: >> Thanks. That's an important clarification to include. Here's the >> revised text: >> >> * >> *

Care must also be exercised when using collections that do >> not permit >> * calling the {@code contains} method with a {@code null} >> value. If either >> * collection does not permit {@code contains(null)} then both >> collections >> * must not contain {@code null} values. >> * >> >> and the @throws text: >> >> * @throws NullPointerException if either collection is {@code >> null}. May >> * also be thrown if one collection contains a {@code null} >> value and the >> * other collection does not permit {@code contains(null)}. > > My concern with this revised wording is that you are now specifying > that the implementation must use contains() ( and not be implemented > using a different strategy ). I guess an alternative implementation is > unlikely, but this does appear overly restricting. > > I wonder if its really necessary to add text to the NPE. A cautionary > note may be sufficient. We could also throw ClassCastException, but > there is no mention of it in the spec. > > Sorry for being a pain about this, I'm just concerned with adding > overly restricting spec. > > Have we thought about catching/swallowing these exceptions? What do you want to do in the catch block ? > > -Chris. R?mi From chris.hegarty at oracle.com Wed Dec 22 15:10:52 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Dec 2010 15:10:52 +0000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D12143D.5030702@univ-mlv.fr> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D12143D.5030702@univ-mlv.fr> Message-ID: <4D1214FC.6080909@oracle.com> On 12/22/10 03:07 PM, R?mi Forax wrote: > Hi Chris, > > On 12/22/2010 02:45 PM, Chris Hegarty wrote: >> Mike, >> >> On 12/21/10 09:38 PM, Mike Duigou wrote: >>> Thanks. That's an important clarification to include. Here's the >>> revised text: >>> >>> * >>> *

Care must also be exercised when using collections that do not >>> permit >>> * calling the {@code contains} method with a {@code null} value. If >>> either >>> * collection does not permit {@code contains(null)} then both >>> collections >>> * must not contain {@code null} values. >>> * >>> >>> and the @throws text: >>> >>> * @throws NullPointerException if either collection is {@code null}. May >>> * also be thrown if one collection contains a {@code null} value and the >>> * other collection does not permit {@code contains(null)}. >> >> My concern with this revised wording is that you are now specifying >> that the implementation must use contains() ( and not be implemented >> using a different strategy ). I guess an alternative implementation is >> unlikely, but this does appear overly restricting. >> >> I wonder if its really necessary to add text to the NPE. A cautionary >> note may be sufficient. We could also throw ClassCastException, but >> there is no mention of it in the spec. >> >> Sorry for being a pain about this, I'm just concerned with adding >> overly restricting spec. >> >> Have we thought about catching/swallowing these exceptions? > > What do you want to do in the catch block ? Would it make sense to simply swallow the exception ( do nothing ) and continue with the next element? Clearly if contains() throws and Exception then the collection does not contain the given element? -Chris. > >> >> -Chris. > > > R?mi > From forax at univ-mlv.fr Wed Dec 22 15:30:59 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 22 Dec 2010 16:30:59 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1214FC.6080909@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D12143D.5030702@univ-mlv.fr> <4D1214FC.6080909@oracle.com> Message-ID: <4D1219B3.8010801@univ-mlv.fr> On 12/22/2010 04:10 PM, Chris Hegarty wrote: > On 12/22/10 03:07 PM, R?mi Forax wrote: >> Hi Chris, >> >> On 12/22/2010 02:45 PM, Chris Hegarty wrote: >>> Mike, >>> >>> On 12/21/10 09:38 PM, Mike Duigou wrote: >>>> Thanks. That's an important clarification to include. Here's the >>>> revised text: >>>> >>>> * >>>> *

Care must also be exercised when using collections that do not >>>> permit >>>> * calling the {@code contains} method with a {@code null} value. If >>>> either >>>> * collection does not permit {@code contains(null)} then both >>>> collections >>>> * must not contain {@code null} values. >>>> * >>>> >>>> and the @throws text: >>>> >>>> * @throws NullPointerException if either collection is {@code >>>> null}. May >>>> * also be thrown if one collection contains a {@code null} value >>>> and the >>>> * other collection does not permit {@code contains(null)}. >>> >>> My concern with this revised wording is that you are now specifying >>> that the implementation must use contains() ( and not be implemented >>> using a different strategy ). I guess an alternative implementation is >>> unlikely, but this does appear overly restricting. >>> >>> I wonder if its really necessary to add text to the NPE. A cautionary >>> note may be sufficient. We could also throw ClassCastException, but >>> there is no mention of it in the spec. >>> >>> Sorry for being a pain about this, I'm just concerned with adding >>> overly restricting spec. >>> >>> Have we thought about catching/swallowing these exceptions? >> >> What do you want to do in the catch block ? > > Would it make sense to simply swallow the exception ( do nothing ) and > continue with the next element? Clearly if contains() throws and > Exception then the collection does not contain the given element? I see, but the same argument can be applied to contains() i.e why doesn't it return false instead of throwing a NPE or a CCE ? > > -Chris. R?mi From chris.hegarty at oracle.com Wed Dec 22 15:55:33 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Dec 2010 15:55:33 +0000 Subject: [concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D121A76.4040203@cytetech.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D12143D.5030702@univ-mlv.fr> <4D1214FC.6080909@oracle.com> <4D121A76.4040203@cytetech.com> Message-ID: <4D121F75.2000001@oracle.com> On 12/22/10 03:34 PM, Gregg Wonderly wrote: > On 12/22/2010 9:10 AM, Chris Hegarty wrote: >> On 12/22/10 03:07 PM, R?mi Forax wrote: >>> On 12/22/2010 02:45 PM, Chris Hegarty wrote: >>>> Have we thought about catching/swallowing these exceptions? >>> >>> What do you want to do in the catch block ? >> >> Would it make sense to simply swallow the exception ( do nothing ) and >> continue >> with the next element? Clearly if contains() throws and Exception then >> the >> collection does not contain the given element? > > It seems that Logger use here might be useful. A FINE level log of the > stack trace would allow the user to discover why the failure/success > return was not as they expected. From some perspectives, I'd be tempted > to log at WARNING for myself as this does represent an unexpected, yet > non-fatal condition in the software. Yes, this is a good proposal. I guess we need to establish whether we consider passing these "incompatible" collections a programmer error or not. I was just trying to ensure that we had considered all options. -Chris. > > Gregg Wonderly From chris.hegarty at oracle.com Wed Dec 22 15:45:23 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Dec 2010 15:45:23 +0000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1219B3.8010801@univ-mlv.fr> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D12143D.5030702@univ-mlv.fr> <4D1214FC.6080909@oracle.com> <4D1219B3.8010801@univ-mlv.fr> Message-ID: <4D121D13.5050002@oracle.com> On 12/22/10 03:30 PM, R?mi Forax wrote: > ... >> >> Would it make sense to simply swallow the exception ( do nothing ) and >> continue with the next element? Clearly if contains() throws and >> Exception then the collection does not contain the given element? > > I see, > but the same argument can be applied to contains() i.e why doesn't it > return false instead of throwing a NPE or a CCE ? Good point. I guess it could be seen as programmer error test for null in a collection that cannot possibly contain it. Although, these exceptions are optional ( in some collections ). For disjoint we don't have this (optional) constraint, and I'm not sure if we should introduce it. Some implementations of disjoint() could already be consuming any NPE/CFE. I'm not saying that this is the right approach, I'm just wondering if we considered this option. -Chris > >> >> -Chris. > > R?mi > From Joel.Kamentz at sas.com Wed Dec 22 16:22:58 2010 From: Joel.Kamentz at sas.com (Joel Kamentz) Date: Wed, 22 Dec 2010 16:22:58 +0000 Subject: Potential memory leak in java.util.logging.Level In-Reply-To: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> References: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> Message-ID: <4FDF98B6ACD1E24387F0A6D7C0064A5A180D7C1F@MERCMBX03R.na.SAS.com> This is definitely a problem with web apps. (I have heard from other teams, but not experienced it myself.) Wouldn't the correct solution be to make the array use weak references? Of course, if it makes sense to expose more of the api (I'm not familiar with it), then do that, too. Joel -----Original Message----- From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Roman Kennke Sent: Wednesday, December 22, 2010 9:36 AM To: core-libs-dev at openjdk.java.net Subject: Potential memory leak in java.util.logging.Level Hello, I believe java.util.logging.Level is potentially memory leaking. This can happen if an application defines its own subclass of Level and is loaded by its own classloader. Level's constructor adds a reference to the new instance of the subclass to its 'known' ArrayList (which is a static field). This instance is never removed from that list. And since this instance holds a reference to its classloader, this means that no classes loaded by that classloader can be unloaded. It could be argued that you should not do crazy stuff with classloaders, but this happens invariably when you deal with applets. I guess similar problems can arise on app servers as well. I wonder why Level's constructors need to be protected though. If they were public, and new Levels could be created simply by instantiating one, this whole problem would not exist. Then the Level.known list would only reference instances of its own class, which would be problematic, unless you create LOTS of levels, which is unlikely. I don't like static collection fields anyway... too prone to leaking. Is this a known problem? Is there a solution to this, except not creating custom log levels? How else could custom log levels be created under those circumstances that would not trigger this problem? Thanks, Roman This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. From chris.hegarty at oracle.com Wed Dec 22 16:34:54 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Dec 2010 16:34:54 +0000 Subject: Potential memory leak in java.util.logging.Level In-Reply-To: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> References: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> Message-ID: <4D1228AE.5060807@oracle.com> On 12/22/10 02:36 PM, Roman Kennke wrote: > Hello, > > I believe java.util.logging.Level is potentially memory leaking. This can happen if an application defines its own subclass of Level and is loaded by its own classloader. Level's constructor adds a reference to the new instance of the subclass to its 'known' ArrayList (which is a static field). This instance is never removed from that list. And since this instance holds a reference to its classloader, this means that no classes loaded by that classloader can be unloaded. It could be argued that you should not do crazy stuff with classloaders, but this happens invariably when you deal with applets. I guess similar problems can arise on app servers as well. > > I wonder why Level's constructors need to be protected though. If they were public, and new Levels could be created simply by instantiating one, this whole problem would not exist. Then the Level.known list would only reference instances of its own class, which would be problematic, unless you create LOTS of levels, which is unlikely. I don't like static collection fields anyway... too prone to leaking. > > Is this a known problem? Is there a solution to this, except not creating custom log levels? How else could custom log levels be created under those circumstances that would not trigger this problem? This would appear to be a known issue, see CR 6992761 [1]. -Chris. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6992761 > > Thanks, > Roman > This communication is for informational purposes only. It is not > intended as an offer or solicitation for the purchase or sale of > any financial instrument or as an official confirmation of any > transaction. All market prices, data and other information are not > warranted as to completeness or accuracy and are subject to change > without notice. Any comments or statements made herein do not > necessarily reflect those of JPMorgan Chase& Co., its subsidiaries > and affiliates. > > This transmission may contain information that is privileged, > confidential, legally privileged, and/or exempt from disclosure > under applicable law. If you are not the intended recipient, you > are hereby notified that any disclosure, copying, distribution, or > use of the information contained herein (including any reliance > thereon) is STRICTLY PROHIBITED. Although this transmission and any > attachments are believed to be free of any virus or other defect > that might affect any computer system into which it is received and > opened, it is the responsibility of the recipient to ensure that it > is virus free and no responsibility is accepted by JPMorgan Chase& > Co., its subsidiaries and affiliates, as applicable, for any loss > or damage arising in any way from its use. If you received this > transmission in error, please immediately contact the sender and > destroy the material in its entirety, whether in electronic or hard > copy format. Thank you. > > Please refer to http://www.jpmorgan.com/pages/disclosures for > disclosures relating to European legal entities. From forax at univ-mlv.fr Wed Dec 22 16:49:41 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 22 Dec 2010 17:49:41 +0100 Subject: [concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D121F75.2000001@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D12143D.5030702@univ-mlv.fr> <4D1214FC.6080909@oracle.com> <4D121A76.4040203@cytetech.com> <4D121F75.2000001@oracle.com> Message-ID: <4D122C25.2050805@univ-mlv.fr> On 12/22/2010 04:55 PM, Chris Hegarty wrote: > On 12/22/10 03:34 PM, Gregg Wonderly wrote: >> On 12/22/2010 9:10 AM, Chris Hegarty wrote: >>> On 12/22/10 03:07 PM, R?mi Forax wrote: >>>> On 12/22/2010 02:45 PM, Chris Hegarty wrote: >>>>> Have we thought about catching/swallowing these exceptions? >>>> >>>> What do you want to do in the catch block ? >>> >>> Would it make sense to simply swallow the exception ( do nothing ) and >>> continue >>> with the next element? Clearly if contains() throws and Exception then >>> the >>> collection does not contain the given element? >> >> It seems that Logger use here might be useful. A FINE level log of the >> stack trace would allow the user to discover why the failure/success >> return was not as they expected. From some perspectives, I'd be tempted >> to log at WARNING for myself as this does represent an unexpected, yet >> non-fatal condition in the software. > > Yes, this is a good proposal. I guess we need to establish whether we > consider passing these "incompatible" collections a programmer error > or not. I was just trying to ensure that we had considered all options. > > -Chris. The main problem with logging is that you may see a lot of records if the application compares huge of collections of turtles and nipples (i.e collections of incompatible type) Moreover if a code relies on catching a CCE in that case, if we log or silently ignore the CCE, the performance will drop. > >> >> Gregg Wonderly R?mi From David.Holmes at oracle.com Wed Dec 22 23:57:44 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 23 Dec 2010 09:57:44 +1000 Subject: [concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D122C25.2050805@univ-mlv.fr> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D12143D.5030702@univ-mlv.fr> <4D1214FC.6080909@oracle.com> <4D121A76.4040203@cytetech.com> <4D121F75.2000001@oracle.com> <4D122C25.2050805@univ-mlv.fr> Message-ID: <4D129078.1040605@oracle.com> I don't think we should be looking at changing the current behaviour at all. Certainly not for JDK7 (rfe for 8 perhaps?) I think the most we can do with the spec is add cautionary (non-normative) notes. David R?mi Forax said the following on 12/23/10 02:49: > On 12/22/2010 04:55 PM, Chris Hegarty wrote: >> On 12/22/10 03:34 PM, Gregg Wonderly wrote: >>> On 12/22/2010 9:10 AM, Chris Hegarty wrote: >>>> On 12/22/10 03:07 PM, R?mi Forax wrote: >>>>> On 12/22/2010 02:45 PM, Chris Hegarty wrote: >>>>>> Have we thought about catching/swallowing these exceptions? >>>>> >>>>> What do you want to do in the catch block ? >>>> >>>> Would it make sense to simply swallow the exception ( do nothing ) and >>>> continue >>>> with the next element? Clearly if contains() throws and Exception then >>>> the >>>> collection does not contain the given element? >>> >>> It seems that Logger use here might be useful. A FINE level log of the >>> stack trace would allow the user to discover why the failure/success >>> return was not as they expected. From some perspectives, I'd be tempted >>> to log at WARNING for myself as this does represent an unexpected, yet >>> non-fatal condition in the software. >> >> Yes, this is a good proposal. I guess we need to establish whether we >> consider passing these "incompatible" collections a programmer error >> or not. I was just trying to ensure that we had considered all options. >> >> -Chris. > > The main problem with logging is that you may see a lot of records > if the application compares huge of collections of turtles and nipples > (i.e collections of incompatible type) > Moreover if a code relies on catching a CCE in that case, if we log or > silently ignore the CCE, > the performance will drop. > >> >>> >>> Gregg Wonderly > > R?mi From mike.duigou at oracle.com Thu Dec 23 01:23:52 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 22 Dec 2010 17:23:52 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1200DE.3040107@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> Message-ID: Here's another try that tries to use similar wording to Collection: * *

Care must also be exercised when using collections that have * restrictions on the elements that they may contain. Collection * implementations are allowed to throw exceptions for any operation * involving elements they deem ineligible. For absolute safety the * specified collections should contain only elements which are * eligible elements for both collections. And for the throws: * @throws NullPointerException if either collection is {@code null}. * @throws NullPointerException if one collection contains a {@code null} * element and {@code null} is not an eligible element for the other collection. * (optional) * @throws ClassCastException if one collection contains an element that is * of a type which is ineligible for the other collection. (optional) On Dec 22 2010, at 05:45 , Chris Hegarty wrote: > My concern with this revised wording is that you are now specifying that the implementation must use contains() ( and not be implemented using a different strategy ). I guess an alternative implementation is unlikely, but this does appear overly restricting. At least four alternate (though impractical) implementations are possible which don't directly use contains() : Collection clone = c1.clone(); for(Object e : c2) { if(clone.remove(e)) { return false; } } and Collection clone = c1.clone(); clone.retainAll(c2); return !clone.isEmpty(); and Collection clone = c1.clone(); clone.removeAll(c2); return clone.size() == c1.size(); and for(Object e : c1) { if(null == e) { for(Object o : c2) { if(null == o) { return false; } } } else { for(Object o : c2) { if((e == o) || ((e.hashCode() == o.hashCode()) && e.equals(o))) { return false; } } } } return true; All but the last use optional operations. The last actually avoids the problem with ineligible elements altogether at a very likely performance cost. I won't suggest we switch to this implementation. ;-) It could also be improved by calculating the hashCodes of all c2 elements, and sorting them into an array to be binary searched for each e. For largish non-Set collections this would actually be faster than the current contains() based impl. > > I wonder if its really necessary to add text to the NPE. A cautionary note may be sufficient. We could also throw ClassCastException, but there is no mention of it in the spec. > > Sorry for being a pain about this, I'm just concerned with adding overly restricting spec. I think your concern is correct. Specifying contains() is too restrictive. > Have we thought about catching/swallowing these exceptions? I'm uncomfortable turning the NPE into a "false" because there may be unknown circumstances such as concurrent modification which could cause the same effect. Mike From valerie.peng at oracle.com Thu Dec 23 03:11:48 2010 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Thu, 23 Dec 2010 03:11:48 +0000 Subject: hg: jdk7/tl/jdk: 6581254: pkcs11 provider fails to parse configuration file contains windows short path Message-ID: <20101223031202.B55874765B@hg.openjdk.java.net> Changeset: d4c2d2d72cfc Author: valeriep Date: 2010-12-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d4c2d2d72cfc 6581254: pkcs11 provider fails to parse configuration file contains windows short path Summary: Modified configuration parsing code to support "~". Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java + test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/csp.cfg From chris.hegarty at oracle.com Thu Dec 23 10:02:19 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Dec 2010 10:02:19 +0000 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> Message-ID: <4D131E2B.1080702@oracle.com> Mike, I'm happy with the latest wording, it looks much better. -Chris. On 23/12/2010 01:23, Mike Duigou wrote: > Here's another try that tries to use similar wording to Collection: > * > *

Care must also be exercised when using collections that have > * restrictions on the elements that they may contain. Collection > * implementations are allowed to throw exceptions for any operation > * involving elements they deem ineligible. For absolute safety the > * specified collections should contain only elements which are > * eligible elements for both collections. > > And for the throws: > > * @throws NullPointerException if either collection is {@code null}. > * @throws NullPointerException if one collection contains a {@code null} > * element and {@code null} is not an eligible element for the other collection. > * (optional) > * @throws ClassCastException if one collection contains an element that is > * of a type which is ineligible for the other collection. (optional) > > > On Dec 22 2010, at 05:45 , Chris Hegarty wrote: > >> My concern with this revised wording is that you are now specifying that the implementation must use contains() ( and not be implemented using a different strategy ). I guess an alternative implementation is unlikely, but this does appear overly restricting. > > At least four alternate (though impractical) implementations are possible which don't directly use contains() : > > Collection clone = c1.clone(); > for(Object e : c2) { > if(clone.remove(e)) { > return false; > } > } > > and > > Collection clone = c1.clone(); > clone.retainAll(c2); > return !clone.isEmpty(); > > and > > Collection clone = c1.clone(); > clone.removeAll(c2); > return clone.size() == c1.size(); > > and > > for(Object e : c1) { > if(null == e) { > for(Object o : c2) { > if(null == o) { > return false; > } > } > } else { > for(Object o : c2) { > if((e == o) || ((e.hashCode() == o.hashCode())&& e.equals(o))) { > return false; > } > } > } > } > return true; > > All but the last use optional operations. The last actually avoids the problem with ineligible elements altogether at a very likely performance cost. I won't suggest we switch to this implementation. ;-) It could also be improved by calculating the hashCodes of all c2 elements, and sorting them into an array to be binary searched for each e. For largish non-Set collections this would actually be faster than the current contains() based impl. > >> >> I wonder if its really necessary to add text to the NPE. A cautionary note may be sufficient. We could also throw ClassCastException, but there is no mention of it in the spec. >> >> Sorry for being a pain about this, I'm just concerned with adding overly restricting spec. > > I think your concern is correct. Specifying contains() is too restrictive. > >> Have we thought about catching/swallowing these exceptions? > > I'm uncomfortable turning the NPE into a "false" because there may be unknown circumstances such as concurrent modification which could cause the same effect. > > Mike From roman.kennke at jpmchase.com Thu Dec 23 10:53:41 2010 From: roman.kennke at jpmchase.com (Roman Kennke) Date: Thu, 23 Dec 2010 11:53:41 +0100 Subject: Potential memory leak in java.util.logging.Level In-Reply-To: <4D1228AE.5060807@oracle.com> References: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> <4D1228AE.5060807@oracle.com> Message-ID: <83F7A3288A69094192A850818614CEEF7A35A2FC3A@EMBACMS102.exchad.jpmchase.net> Hi Chris, (Sorry for top-posting, my stupid email program cannot do proper quoting) I don't understand why the CR is a 'request for enhancement' with 'very low' priority. A memory leak should be a bug with at least high priority in my world view. I will see if I find time to implement a fix. **Roman -----Original Message----- From: Chris Hegarty [mailto:chris.hegarty at oracle.com] Sent: 22 December 2010 17:35 To: Roman Kennke Cc: core-libs-dev at openjdk.java.net Subject: Re: Potential memory leak in java.util.logging.Level On 12/22/10 02:36 PM, Roman Kennke wrote: > Hello, > > I believe java.util.logging.Level is potentially memory leaking. This can happen if an application defines its own subclass of Level and is loaded by its own classloader. Level's constructor adds a reference to the new instance of the subclass to its 'known' ArrayList (which is a static field). This instance is never removed from that list. And since this instance holds a reference to its classloader, this means that no classes loaded by that classloader can be unloaded. It could be argued that you should not do crazy stuff with classloaders, but this happens invariably when you deal with applets. I guess similar problems can arise on app servers as well. > > I wonder why Level's constructors need to be protected though. If they were public, and new Levels could be created simply by instantiating one, this whole problem would not exist. Then the Level.known list would only reference instances of its own class, which would be problematic, unless you create LOTS of levels, which is unlikely. I don't like static collection fields anyway... too prone to leaking. > > Is this a known problem? Is there a solution to this, except not creating custom log levels? How else could custom log levels be created under those circumstances that would not trigger this problem? This would appear to be a known issue, see CR 6992761 [1]. -Chris. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6992761 > > Thanks, > Roman > This communication is for informational purposes only. It is not > intended as an offer or solicitation for the purchase or sale of > any financial instrument or as an official confirmation of any > transaction. All market prices, data and other information are not > warranted as to completeness or accuracy and are subject to change > without notice. Any comments or statements made herein do not > necessarily reflect those of JPMorgan Chase& Co., its subsidiaries > and affiliates. > > This transmission may contain information that is privileged, > confidential, legally privileged, and/or exempt from disclosure > under applicable law. If you are not the intended recipient, you > are hereby notified that any disclosure, copying, distribution, or > use of the information contained herein (including any reliance > thereon) is STRICTLY PROHIBITED. Although this transmission and any > attachments are believed to be free of any virus or other defect > that might affect any computer system into which it is received and > opened, it is the responsibility of the recipient to ensure that it > is virus free and no responsibility is accepted by JPMorgan Chase& > Co., its subsidiaries and affiliates, as applicable, for any loss > or damage arising in any way from its use. If you received this > transmission in error, please immediately contact the sender and > destroy the material in its entirety, whether in electronic or hard > copy format. Thank you. > > Please refer to http://www.jpmorgan.com/pages/disclosures for > disclosures relating to European legal entities. From chris.hegarty at oracle.com Thu Dec 23 13:33:06 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Dec 2010 13:33:06 +0000 Subject: Potential memory leak in java.util.logging.Level In-Reply-To: <83F7A3288A69094192A850818614CEEF7A35A2FC3A@EMBACMS102.exchad.jpmchase.net> References: <83F7A3288A69094192A850818614CEEF7A35A2F96F@EMBACMS102.exchad.jpmchase.net> <4D1228AE.5060807@oracle.com> <83F7A3288A69094192A850818614CEEF7A35A2FC3A@EMBACMS102.exchad.jpmchase.net> Message-ID: <4D134F92.4070500@oracle.com> On 23/12/2010 10:53, Roman Kennke wrote: > Hi Chris, > > (Sorry for top-posting, my stupid email program cannot do proper quoting) > > I don't understand why the CR is a 'request for enhancement' with 'very low' priority. A memory leak should be a bug with at least high priority in my world view. I agree, it should be marked as a bug and a P3 (Medium Priority). I'll see if I can locate the area (java.util.logging) owner and have the bug updated. > I will see if I find time to implement a fix. Thanks, that would be great. -Chris. > > **Roman > > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: 22 December 2010 17:35 > To: Roman Kennke > Cc: core-libs-dev at openjdk.java.net > Subject: Re: Potential memory leak in java.util.logging.Level > > On 12/22/10 02:36 PM, Roman Kennke wrote: >> Hello, >> >> I believe java.util.logging.Level is potentially memory leaking. This can happen if an application defines its own subclass of Level and is loaded by its own classloader. Level's constructor adds a reference to the new instance of the subclass to its 'known' ArrayList (which is a static field). This instance is never removed from that list. And since this instance holds a reference to its classloader, this means that no classes loaded by that classloader can be unloaded. It could be argued that you should not do crazy stuff with classloaders, but this happens invariably when you deal with applets. I guess similar problems can arise on app servers as well. >> >> I wonder why Level's constructors need to be protected though. If they were public, and new Levels could be created simply by instantiating one, this whole problem would not exist. Then the Level.known list would only reference instances of its own class, which would be problematic, unless you create LOTS of levels, which is unlikely. I don't like static collection fields anyway... too prone to leaking. >> >> Is this a known problem? Is there a solution to this, except not creating custom log levels? How else could custom log levels be created under those circumstances that would not trigger this problem? > > This would appear to be a known issue, see CR 6992761 [1]. > > -Chris. > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6992761 > >> >> Thanks, >> Roman >> This communication is for informational purposes only. It is not >> intended as an offer or solicitation for the purchase or sale of >> any financial instrument or as an official confirmation of any >> transaction. All market prices, data and other information are not >> warranted as to completeness or accuracy and are subject to change >> without notice. Any comments or statements made herein do not >> necessarily reflect those of JPMorgan Chase& Co., its subsidiaries >> and affiliates. >> >> This transmission may contain information that is privileged, >> confidential, legally privileged, and/or exempt from disclosure >> under applicable law. If you are not the intended recipient, you >> are hereby notified that any disclosure, copying, distribution, or >> use of the information contained herein (including any reliance >> thereon) is STRICTLY PROHIBITED. Although this transmission and any >> attachments are believed to be free of any virus or other defect >> that might affect any computer system into which it is received and >> opened, it is the responsibility of the recipient to ensure that it >> is virus free and no responsibility is accepted by JPMorgan Chase& >> Co., its subsidiaries and affiliates, as applicable, for any loss >> or damage arising in any way from its use. If you received this >> transmission in error, please immediately contact the sender and >> destroy the material in its entirety, whether in electronic or hard >> copy format. Thank you. >> >> Please refer to http://www.jpmorgan.com/pages/disclosures for >> disclosures relating to European legal entities. From lana.steuck at oracle.com Thu Dec 23 16:45:32 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 16:45:32 +0000 Subject: hg: jdk7/tl/corba: 8 new changesets Message-ID: <20101223164537.7209A476A1@hg.openjdk.java.net> Changeset: ccc68bc57c82 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/ccc68bc57c82 Added tag jdk7-b122 for changeset 1523a060032c ! .hgtags Changeset: 88ac4daf5d0e Author: yhuang Date: 2010-12-05 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/88ac4daf5d0e 6925851: Localize JRE into pt_BR Reviewed-by: mfang, psun + src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties Changeset: 2367ae41663f Author: mfang Date: 2010-12-05 18:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/2367ae41663f Merge Changeset: 0bf5592fb265 Author: ohair Date: 2010-12-15 15:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0bf5592fb265 Merge Changeset: e8188d64f51f Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e8188d64f51f Merge Changeset: 39e071e5adaf Author: ohair Date: 2010-12-18 18:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/39e071e5adaf 6909026: Change GNU make version requirement to 3.81 Reviewed-by: robilad ! make/common/shared/Platform.gmk Changeset: a230c142628c Author: lana Date: 2010-12-20 17:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/a230c142628c Merge Changeset: 70cff21e5550 Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/70cff21e5550 Added tag jdk7-b123 for changeset a230c142628c ! .hgtags From lana.steuck at oracle.com Thu Dec 23 16:49:51 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 16:49:51 +0000 Subject: hg: jdk7/tl: 17 new changesets Message-ID: <20101223164951.D4D10476A2@hg.openjdk.java.net> Changeset: d61adc5101e0 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d61adc5101e0 Added tag jdk7-b122 for changeset f1591eed71f6 ! .hgtags Changeset: 55566844106b Author: ohair Date: 2010-12-06 10:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/55566844106b 7001720: copyright templates not rebranded Reviewed-by: mchung ! make/templates/bsd-header ! make/templates/gpl-cp-header ! make/templates/gpl-header Changeset: 5be437606a75 Author: ohair Date: 2010-12-15 15:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/5be437606a75 Merge Changeset: d94daa2acb2c Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d94daa2acb2c Merge Changeset: f4c95f4b7590 Author: ohair Date: 2010-12-18 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f4c95f4b7590 6909026: Change GNU make version requirement to 3.81 Reviewed-by: robilad ! README ! README-builds.html Changeset: 6d8ed82e5070 Author: ohair Date: 2010-12-20 08:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6d8ed82e5070 6909331: Add vsvars.sh to the jdk repository (handy cygwin way to get vcvars32.bat run) Reviewed-by: robilad + make/scripts/vsvars.sh Changeset: 2dfa4b3ffb15 Author: jqzuo Date: 2010-12-01 14:35 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/2dfa4b3ffb15 Merge Changeset: 58a44f077f6a Author: jqzuo Date: 2010-12-09 16:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/58a44f077f6a Merge Changeset: 89f2e9a9ea8e Author: jqzuo Date: 2010-12-13 11:34 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/89f2e9a9ea8e Merge Changeset: 8f03f266666a Author: jqzuo Date: 2010-12-20 13:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/8f03f266666a Merge Changeset: 6f7376db67f8 Author: jqzuo Date: 2010-12-21 11:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6f7376db67f8 Merge Changeset: e6a650447dfe Author: igor Date: 2010-12-06 00:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e6a650447dfe Merge Changeset: 9dd65b426626 Author: igor Date: 2010-12-08 01:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9dd65b426626 Merge Changeset: c71d8feeb2ea Author: herrick Date: 2010-12-12 22:56 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/c71d8feeb2ea Merge Changeset: ca5471357681 Author: herrick Date: 2010-12-20 13:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/ca5471357681 Merge Changeset: ed6950da30cf Author: igor Date: 2010-12-21 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/ed6950da30cf Merge Changeset: 4c20b4f753e3 Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4c20b4f753e3 Added tag jdk7-b123 for changeset ed6950da30cf ! .hgtags From lana.steuck at oracle.com Thu Dec 23 16:50:58 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 16:50:58 +0000 Subject: hg: jdk7/tl/hotspot: 89 new changesets Message-ID: <20101223165331.BF299476A3@hg.openjdk.java.net> Changeset: 1132ed4a0086 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1132ed4a0086 Added tag jdk7-b122 for changeset 3a548dc9cb45 ! .hgtags Changeset: 33bfde7da72a Author: trims Date: 2010-12-03 09:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/33bfde7da72a Added tag hs20-b03 for changeset 5484e7c53fa7 ! .hgtags Changeset: 058f494c8b6d Author: trims Date: 2010-12-10 15:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/058f494c8b6d Merge ! .hgtags Changeset: 81fc264cf826 Author: trims Date: 2010-12-16 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/81fc264cf826 Merge ! .hgtags Changeset: 899bbbdcb6ea Author: ysr Date: 2010-11-05 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/899bbbdcb6ea 6997298: fatal error: must own lock CMS_markBitMap_lock during heap dump Summary: Since we are at a stop-world pause, the existing CMS-phase checks are sufficient for safety, and the locking check can be safely elided. Elaborated documentation comment to the case where class unloading and verification are disabled, and the query happens when we aren't in the sweeping phase, where the answer "false" would be (almost everywhere) too pessimistic. Reviewed-by: jmasa, johnc, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 4df7f8cba524 Author: ysr Date: 2010-11-09 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4df7f8cba524 6996613: CompactibleFreeListSpace::print should call CompactibleFreeListSpace::print_on, not Space::print_on Reviewed-by: tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 8d81b4a1d3e1 Author: ysr Date: 2010-11-11 10:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8d81b4a1d3e1 6998802: ScavengeALot: assert(!gch->incremental_collection_failed()) failed: Twice in a row Summary: Weaken assert by excluding scavenges resulting from -XX:+ScavengeALot stress-testing option. Reviewed-by: jmasa, tonyp ! src/share/vm/memory/defNewGeneration.cpp Changeset: e3e1fb85e50a Author: jmasa Date: 2010-11-15 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e3e1fb85e50a Merge Changeset: 1070423b51f3 Author: kamg Date: 2010-10-27 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1070423b51f3 6865028: Illegal instructions passing verification prior to 'invokespecial Object.' Summary: Update verifier to conform to spec re: reference vs. 'Object' types Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp Changeset: 35f885165c69 Author: kamg Date: 2010-11-05 09:32 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/35f885165c69 6981737: The java.vm.specification.version property is 1.0, seems like it should be 2.0 Summary: Change property value to 1. for major_version >= 7 Reviewed-by: dholmes, acorn ! src/share/vm/runtime/arguments.cpp + test/runtime/6981737/Test6981737.java Changeset: 9752a6549f2e Author: zgu Date: 2010-11-12 09:37 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9752a6549f2e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 13fee5052895 Author: zgu Date: 2010-11-17 09:21 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/13fee5052895 Merge Changeset: 9eecf81a02fb Author: ysr Date: 2010-11-16 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9eecf81a02fb 7000578: CMS: assert(SafepointSynchronize::is_at_safepoint()) failed: Else races are possible Summary: Weakened assert in onj_is_alive() to allow its use at initialization time when is_at_safepoint() normally reports false; added some related asserts to check order of is_init_completed() after Universe::is_fully_initialized(). Reviewed-by: jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/init.cpp Changeset: 878b57474103 Author: johnc Date: 2010-11-16 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/878b57474103 6978187: G1: assert(ParallelGCThreads> 1 || n_yielded() == _hrrs->occupied()) strikes again Summary: An evacuation failure while copying the roots caused an object, A, to be forwarded to itself. During the subsequent RSet updating a reference to A was processed causing the reference to be added to the RSet of A's heap region. As a result of adding to the remembered set we ran into the issue described in 6930581 - the sparse table expanded and the RSet scanning code walked the cards in one instance of RHashTable (_cur) while the occupied() counts the cards in the expanded table (_next). Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp Changeset: deef066c3622 Author: johnc Date: 2010-11-16 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/deef066c3622 Merge Changeset: 0be53e62c06c Author: jmasa Date: 2010-11-19 13:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0be53e62c06c Merge Changeset: 0ac62b4d6507 Author: kvn Date: 2010-11-12 09:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0ac62b4d6507 6999491: non-zero COOPs are used when they should not Summary: HeapBaseMinAddress should be used only for a default heap size calculation. Reviewed-by: iveresov, jcoomes, dholmes ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 22ef3370343b Author: iveresov Date: 2010-11-16 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22ef3370343b 7000349: Tiered reacts incorrectly to C1 compilation failures Summary: Fix policy reaction to C1 comilation failures, make C1 properly report errors. Reviewed-by: kvn ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp Changeset: f264f4c42799 Author: kvn Date: 2010-11-18 09:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f264f4c42799 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre Summary: Wrong value type is used for NULL store when clearing the detail message of the preallocated exception object. Reviewed-by: never, iveresov ! src/share/vm/opto/graphKit.cpp Changeset: 4110c3e0c50d Author: iveresov Date: 2010-11-19 17:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4110c3e0c50d Merge ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 22260322f0be Author: zgu Date: 2010-11-18 14:37 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22260322f0be 6751923: JNDI wake up when clock_settime() is called Summary: Ported Chris Phillips' patch from jdk5 to jdk7 Reviewed-by: chrisphi, coleenp ! src/os/solaris/vm/os_solaris.cpp Changeset: 0b33f0736406 Author: poonam Date: 2010-11-19 03:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0b33f0736406 6837842: JNI_CreateJavaVM crashes under impersonation Reviewed-by: acorn, dholmes ! src/os/windows/vm/perfMemory_windows.cpp Changeset: a6b067997c7e Author: coleenp Date: 2010-11-19 23:46 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a6b067997c7e Merge Changeset: b675ff1ca7a3 Author: twisti Date: 2010-11-23 04:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b675ff1ca7a3 7002129: Zero and Shark fixes, 3rd Summary: 6970683 and 6953144 introduced changes that need to be implemented for Zero and Shark. Reviewed-by: twisti Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/share/vm/compiler/compileBroker.cpp Changeset: e33f46fc48ed Author: coleenp Date: 2010-11-23 15:01 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e33f46fc48ed Merge Changeset: f95d63e2154a Author: stefank Date: 2010-11-23 13:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f95d63e2154a 6989984: Use standard include model for Hospot Summary: Replaced MakeDeps and the includeDB files with more standardized solutions. Reviewed-by: coleenp, kvn, kamg ! make/linux/makefiles/adlc.make ! make/linux/makefiles/amd64.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/core.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/i486.make ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/launcher.make - make/linux/makefiles/makedeps.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/sparc.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/sparcv9.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/linux/makefiles/zero.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/amd64.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/core.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/i486.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/launcher.make - make/solaris/makefiles/makedeps.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/sparcv9.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make - make/windows/README ! make/windows/create.bat + make/windows/create_obj_files.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/generated.make - make/windows/makefiles/makedeps.make ! make/windows/makefiles/product.make + make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! make/windows/projectfiles/compiler2/Makefile ! make/windows/projectfiles/kernel/Makefile ! make/windows/projectfiles/tiered/Makefile ! 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/bytecodeInterpreter_sparc.cpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.hpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp ! src/cpu/sparc/vm/bytecodes_sparc.cpp ! src/cpu/sparc/vm/bytecodes_sparc.hpp ! src/cpu/sparc/vm/bytes_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FpuStackSim_sparc.cpp ! src/cpu/sparc/vm/c1_FpuStackSim_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.cpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/cppInterpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.hpp ! src/cpu/sparc/vm/debug_sparc.cpp ! src/cpu/sparc/vm/depChecker_sparc.cpp ! src/cpu/sparc/vm/depChecker_sparc.hpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreterRT_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.hpp ! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/jniTypes_sparc.hpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/register_definitions_sparc.cpp ! src/cpu/sparc/vm/register_sparc.cpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vmreg_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.hpp ! src/cpu/sparc/vm/vmreg_sparc.inline.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/bytecodes_x86.cpp ! src/cpu/x86/vm/bytecodes_x86.hpp ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Defs_x86.hpp ! src/cpu/x86/vm/c1_FpuStackSim_x86.cpp ! src/cpu/x86/vm/c1_FpuStackSim_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/c2_init_x86.cpp ! src/cpu/x86/vm/codeBuffer_x86.hpp ! src/cpu/x86/vm/copy_x86.hpp ! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.hpp ! src/cpu/x86/vm/debug_x86.cpp ! src/cpu/x86/vm/depChecker_x86.cpp ! src/cpu/x86/vm/depChecker_x86.hpp ! src/cpu/x86/vm/disassembler_x86.hpp ! src/cpu/x86/vm/dump_x86_32.cpp ! src/cpu/x86/vm/dump_x86_64.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/icache_x86.hpp ! 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/interpreterRT_x86.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/javaFrameAnchor_x86.hpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/jniTypes_x86.hpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/registerMap_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/register_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86.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/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/vmreg_x86.cpp ! src/cpu/x86/vm/vmreg_x86.hpp ! src/cpu/x86/vm/vmreg_x86.inline.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/cpu/zero/vm/assembler_zero.inline.hpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.cpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp ! src/cpu/zero/vm/bytecodes_zero.cpp ! src/cpu/zero/vm/bytecodes_zero.hpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/cpu/zero/vm/codeBuffer_zero.hpp ! src/cpu/zero/vm/copy_zero.hpp ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/debug_zero.cpp ! src/cpu/zero/vm/depChecker_zero.cpp ! src/cpu/zero/vm/depChecker_zero.hpp ! src/cpu/zero/vm/disassembler_zero.cpp ! src/cpu/zero/vm/disassembler_zero.hpp ! src/cpu/zero/vm/dump_zero.cpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/entry_zero.hpp ! src/cpu/zero/vm/fakeStubFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/globalDefinitions_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/icache_zero.cpp ! src/cpu/zero/vm/icache_zero.hpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreterFrame_zero.hpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreterRT_zero.cpp ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/interpreter_zero.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/cpu/zero/vm/jniFastGetField_zero.cpp ! src/cpu/zero/vm/jniTypes_zero.hpp ! src/cpu/zero/vm/jni_zero.h ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/registerMap_zero.hpp ! src/cpu/zero/vm/register_definitions_zero.cpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stack_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.hpp ! src/cpu/zero/vm/templateInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/templateInterpreter_zero.cpp ! src/cpu/zero/vm/templateInterpreter_zero.hpp ! src/cpu/zero/vm/templateTable_zero.cpp ! src/cpu/zero/vm/templateTable_zero.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/cpu/zero/vm/vm_version_zero.cpp ! src/cpu/zero/vm/vm_version_zero.hpp ! src/cpu/zero/vm/vmreg_zero.cpp ! src/cpu/zero/vm/vmreg_zero.hpp ! src/cpu/zero/vm/vmreg_zero.inline.hpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/linux/launcher/java_md.h ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/c1_globals_linux.hpp ! src/os/linux/vm/c2_globals_linux.hpp ! src/os/linux/vm/chaitin_linux.cpp ! src/os/linux/vm/dtraceJSDT_linux.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/hpi_linux.cpp ! src/os/linux/vm/hpi_linux.hpp ! src/os/linux/vm/interfaceSupport_linux.hpp ! src/os/linux/vm/jsig.c ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/os_share_linux.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/linux/vm/stubRoutines_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/linux/vm/vmError_linux.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/generateJvmOffsets.h ! src/os/solaris/dtrace/generateJvmOffsetsMain.c ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/dtrace/jvm_dtrace.h ! src/os/solaris/dtrace/libjvm_db.h ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/os/solaris/launcher/java_md.h ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/c1_globals_solaris.hpp ! src/os/solaris/vm/c2_globals_solaris.hpp ! src/os/solaris/vm/chaitin_solaris.cpp ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/hpi_solaris.cpp ! src/os/solaris/vm/hpi_solaris.hpp ! src/os/solaris/vm/interfaceSupport_solaris.hpp ! src/os/solaris/vm/jsig.c ! src/os/solaris/vm/jvm_solaris.cpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_share_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/solaris/vm/stubRoutines_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/solaris/vm/vmError_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/os/windows/vm/c1_globals_windows.hpp ! src/os/windows/vm/c2_globals_windows.hpp ! src/os/windows/vm/chaitin_windows.cpp ! src/os/windows/vm/dtraceJSDT_windows.cpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/hpi_windows.cpp ! src/os/windows/vm/hpi_windows.hpp ! src/os/windows/vm/interfaceSupport_windows.hpp ! src/os/windows/vm/jvm_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/osThread_windows.cpp ! src/os/windows/vm/osThread_windows.hpp ! src/os/windows/vm/os_share_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os/windows/vm/stubRoutines_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os/windows/vm/vmError_windows.cpp ! src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/prefetch_linux_sparc.inline.hpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/bytes_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/copy_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/prefetch_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vm_version_linux_x86.cpp ! src/os_cpu/linux_zero/vm/assembler_linux_zero.cpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/bytes_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp ! src/os_cpu/linux_zero/vm/prefetch_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/linux_zero/vm/vm_version_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.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_sparc/vm/prefetch_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/bytes_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/copy_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.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/solaris_x86/vm/prefetch_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/vm_version_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/bytes_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/globals_windows_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/os_cpu/windows_x86/vm/prefetch_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vm_version_windows_x86.cpp - src/share/tools/MakeDeps/ArgsParser.java - src/share/tools/MakeDeps/BuildConfig.java - src/share/tools/MakeDeps/Database.java - src/share/tools/MakeDeps/DirectoryTree.java - src/share/tools/MakeDeps/DirectoryTreeNode.java - src/share/tools/MakeDeps/FileFormatException.java - src/share/tools/MakeDeps/FileList.java - src/share/tools/MakeDeps/FileName.java - src/share/tools/MakeDeps/Macro.java - src/share/tools/MakeDeps/MacroDefinitions.java - src/share/tools/MakeDeps/MakeDeps.java - src/share/tools/MakeDeps/MetroWerksMacPlatform.java - src/share/tools/MakeDeps/Platform.java - src/share/tools/MakeDeps/UnixPlatform.java - src/share/tools/MakeDeps/Util.java - src/share/tools/MakeDeps/WinGammaPlatform.java - src/share/tools/MakeDeps/WinGammaPlatformVC6.java - src/share/tools/MakeDeps/WinGammaPlatformVC7.java - src/share/tools/MakeDeps/WinGammaPlatformVC8.java - src/share/tools/MakeDeps/WinGammaPlatformVC9.java + src/share/tools/ProjectCreator/ArgsParser.java + src/share/tools/ProjectCreator/BuildConfig.java + src/share/tools/ProjectCreator/DirectoryTree.java + src/share/tools/ProjectCreator/DirectoryTreeNode.java + src/share/tools/ProjectCreator/FileFormatException.java + src/share/tools/ProjectCreator/Macro.java + src/share/tools/ProjectCreator/MacroDefinitions.java + src/share/tools/ProjectCreator/ProjectCreator.java + src/share/tools/ProjectCreator/Util.java + src/share/tools/ProjectCreator/WinGammaPlatform.java + src/share/tools/ProjectCreator/WinGammaPlatformVC6.java + src/share/tools/ProjectCreator/WinGammaPlatformVC7.java + src/share/tools/ProjectCreator/WinGammaPlatformVC8.java + src/share/tools/ProjectCreator/WinGammaPlatformVC9.java ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/adlc/adlc.hpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/arena.cpp ! src/share/vm/adlc/arena.hpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/dict2.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/asm/register.cpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_CFGPrinter.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_Defs.cpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Optimizer.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueSet.cpp ! src/share/vm/c1/c1_ValueSet.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciArrayKlassKlass.hpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciCPCache.hpp ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.cpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciConstantPoolCache.cpp ! src/share/vm/ci/ciConstantPoolCache.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciExceptionHandler.cpp ! src/share/vm/ci/ciExceptionHandler.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciFlags.cpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstance.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciInstanceKlassKlass.cpp ! src/share/vm/ci/ciInstanceKlassKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciKlassKlass.cpp ! src/share/vm/ci/ciKlassKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciMethodBlocks.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciMethodKlass.cpp ! src/share/vm/ci/ciMethodKlass.hpp ! src/share/vm/ci/ciNullObject.cpp ! src/share/vm/ci/ciNullObject.hpp ! src/share/vm/ci/ciObjArray.cpp ! src/share/vm/ci/ciObjArray.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjArrayKlassKlass.cpp ! src/share/vm/ci/ciObjArrayKlassKlass.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciSymbolKlass.cpp ! src/share/vm/ci/ciSymbolKlass.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/ci/ciTypeArray.hpp ! src/share/vm/ci/ciTypeArrayKlass.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/ci/ciTypeArrayKlassKlass.cpp ! src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/ci/ciUtilities.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.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/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/code/compressedStream.hpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/exceptionHandlerTable.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/location.cpp ! src/share/vm/code/location.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/oopRecorder.cpp ! src/share/vm/code/oopRecorder.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/compiler/methodLiveness.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsLockVerifier.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsLockVerifier.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/g1_globals.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp - src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep - src/share/vm/gc_implementation/includeDB_gc_g1 - src/share/vm/gc_implementation/includeDB_gc_parNew - src/share/vm/gc_implementation/includeDB_gc_parallelScavenge - src/share/vm/gc_implementation/includeDB_gc_serial - src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parNew/vmStructs_parNew.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmStructs_parallelgc.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.cpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.cpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/liveRange.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.cpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp - src/share/vm/includeDB_compiler1 - src/share/vm/includeDB_compiler2 - src/share/vm/includeDB_core - src/share/vm/includeDB_features - src/share/vm/includeDB_gc - src/share/vm/includeDB_gc_parallel - src/share/vm/includeDB_jvmti - src/share/vm/includeDB_shark - src/share/vm/includeDB_zero ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeHistogram.cpp ! src/share/vm/interpreter/bytecodeHistogram.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodeTracer.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.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/libadt/dict.cpp ! src/share/vm/libadt/dict.hpp ! src/share/vm/libadt/port.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/set.hpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/blockOffsetTable.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/classify.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/compactPermGen.hpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.inline.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genMarkSweep.hpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/genRemSet.inline.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generation.inline.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/generationSpec.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp ! src/share/vm/memory/specialized_oop_closures.cpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/memory/universe.inline.hpp ! src/share/vm/memory/watermark.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/arrayKlassKlass.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.hpp ! src/share/vm/oops/compiledICHolderOop.cpp ! src/share/vm/oops/compiledICHolderOop.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceOop.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassKlass.hpp ! src/share/vm/oops/klassOop.cpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/markOop.inline.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodDataKlass.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/symbolKlass.cpp ! src/share/vm/oops/symbolKlass.hpp ! src/share/vm/oops/symbolOop.cpp ! src/share/vm/oops/symbolOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/oops/typeArrayKlassKlass.cpp ! src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/oops/typeArrayOop.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/addnode.hpp ! src/share/vm/opto/adlcVMDeps.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/divnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/indexSet.cpp ! src/share/vm/opto/indexSet.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/rootnode.cpp ! src/share/vm/opto/rootnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + src/share/vm/precompiled.hpp ! src/share/vm/prims/evmCompat.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/hpi_imported.h ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jniFastGetField.cpp ! src/share/vm/prims/jniFastGetField.hpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiAgentThread.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnv.xsl ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiEventController.hpp ! src/share/vm/prims/jvmtiEventController.inline.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.hpp ! src/share/vm/prims/jvmtiHpp.xsl ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/prims/jvmtiManageCapabilities.hpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/jvmtiThreadState.inline.hpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/jvmtiTrace.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/prims/jvmtiUtil.hpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodComparator.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/prims/perf.cpp ! src/share/vm/prims/privilegedStack.cpp ! src/share/vm/prims/privilegedStack.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/basicLock.cpp ! src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/biasedLocking.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/extendedPC.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/hpi.cpp ! src/share/vm/runtime/hpi.hpp ! src/share/vm/runtime/icache.cpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/init.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jfieldIDWorkaround.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/jniPeriodicChecker.cpp ! src/share/vm/runtime/jniPeriodicChecker.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/memprofiler.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.cpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/park.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/prefetch.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionCompat.hpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/rframe.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.inline.hpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/stackValue.hpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/stackValueCollection.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/statSampler.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadCritical.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/dtraceAttacher.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/memoryUsage.hpp ! src/share/vm/services/psMemoryPool.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/runtimeService.hpp ! src/share/vm/services/serviceUtil.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/llvmValue.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBlock.hpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkBuilder.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkCacheDecache.hpp ! src/share/vm/shark/sharkCodeBuffer.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkConstant.hpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkEntry.hpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkFunction.hpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkInliner.hpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkIntrinsics.hpp ! src/share/vm/shark/sharkInvariants.cpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/shark/sharkNativeWrapper.hpp ! src/share/vm/shark/sharkRuntime.cpp ! src/share/vm/shark/sharkRuntime.hpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkStack.hpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkState.hpp ! src/share/vm/shark/sharkStateScanner.cpp ! src/share/vm/shark/sharkStateScanner.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkTopLevelBlock.hpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/shark/sharkValue.cpp ! src/share/vm/shark/sharkValue.hpp ! src/share/vm/shark/shark_globals.cpp ! src/share/vm/shark/shark_globals.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/copy.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/defaultStream.hpp ! src/share/vm/utilities/dtrace.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/preserveException.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/sizes.cpp ! src/share/vm/utilities/sizes.hpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 631f79e71e90 Author: tonyp Date: 2010-08-24 17:24 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/631f79e71e90 6974966: G1: unnecessary direct-to-old allocations Summary: This change revamps the slow allocation path of G1. Improvements include the following: a) Allocations directly to old regions are now totally banned. G1 now only allows allocations out of young regions (with the only exception being humongous regions). b) The thread that allocates a new region (which is now guaranteed to be young) does not dirty all its cards. Each thread that successfully allocates out of a young region is now responsible for dirtying the cards that corresponding to the "block" that just got allocated. c) allocate_new_tlab() and mem_allocate() are now implemented differently and TLAB allocations are only done by allocate_new_tlab(). d) If a thread schedules an evacuation pause in order to satisfy an allocation request, it will perform the allocation at the end of the safepoint so that the thread that initiated the GC also gets "first pick" of any space made available by the GC. e) If a thread is unable to allocate a humongous object it will schedul e an evacuation pause in case it reclaims enough regions so that the humongous allocation can be satisfied aftewards. f) The G1 policy is more careful to set the young list target length to be the survivor number +1. g) Lots of code tidy up, removal, refactoring to make future changes easier. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp Changeset: fd1d227ef1b9 Author: johnc Date: 2010-12-01 17:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fd1d227ef1b9 6983204: G1: Nightly test nsk/regression/b4958615 failing with +ExplicitGCInvokesConcurrent Summary: Enable reference discovery during concurrent marking by setting the reference processor field of the concurrent marking closure. Keep reference objects on the discovered reference lists alive during incremental evacuation pauses until they are processed at the end of concurrent marking. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/thread.hpp Changeset: d9310331a29c Author: tonyp Date: 2010-12-02 13:20 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d9310331a29c 7003860: G1: assert(_cur_alloc_region == NULL || !expect_null_cur_alloc_region) fails Summary: Wrong assumption about expecting the current alloc region expected to be NULL in expand_and_allocate(). Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0fc262af204f Author: coleenp Date: 2010-11-29 15:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0fc262af204f 6780143: hs203t003 hits SIGSEGV/EXCEPTION_ACCESS_VIOLATION with -XX:+UseCompressedOops Summary: Using r12 as temporary register around call_VM trashes heapbase becausecall_VM doesn't always return immediately to following code (eg forward_exception, popframe and early return support). Reviewed-by: never, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: c7db7adb83b4 Author: ohair Date: 2010-11-30 18:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c7db7adb83b4 6987107: Add variable to add to but not modify non-fcs version string Reviewed-by: jcoomes, dholmes, andrew, kvn ! make/defs.make ! make/jprt.gmk ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! make/windows/projectfiles/common/Makefile Changeset: 2ca799d83d3c Author: ohair Date: 2010-11-30 18:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2ca799d83d3c Merge ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! make/windows/projectfiles/common/Makefile Changeset: 01c0559441c8 Author: brutisso Date: 2010-12-01 03:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/01c0559441c8 7003456: ADLC files not correctly generated on Windows Summary: Added target architecture parameters to make ADLC build properly Reviewed-by: never, stefank ! make/windows/makefiles/adlc.make Changeset: 828eafbd85cc Author: ikrylov Date: 2010-12-01 18:26 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/828eafbd85cc 6348631: remove the use of the HPI library from Hotspot Summary: move functions from hpi library to hotspot, communicate with licensees and open source community, check jdk for dependency, file CCC request Reviewed-by: coleenp, acorn, dsamersoff ! src/cpu/sparc/vm/depChecker_sparc.cpp ! src/cpu/x86/vm/depChecker_x86.cpp ! src/cpu/zero/vm/depChecker_zero.cpp - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/precompiled.hpp - src/share/vm/prims/hpi_imported.h ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 3c205c4f1cda Author: coleenp Date: 2010-12-01 18:32 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3c205c4f1cda Merge - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp - src/share/vm/prims/hpi_imported.h - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 6a2d73358ff7 Author: bobv Date: 2010-12-02 14:00 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6a2d73358ff7 7004217: Remove IA64 workaround re-introduced with CR6953477 Summary: gcc bug worksaround for IA64 no longer needed Reviewed-by: andrew ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: c760f78e0a53 Author: stefank Date: 2010-12-01 15:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c760f78e0a53 7003125: precompiled.hpp is included when precompiled headers are not used Summary: Added an ifndef DONT_USE_PRECOMPILED_HEADER to precompiled.hpp. Set up DONT_USE_PRECOMPILED_HEADER when compiling with Sun Studio or when the user specifies USE_PRECOMPILED_HEADER=0. Fixed broken include dependencies. Reviewed-by: coleenp, kvn ! make/linux/makefiles/gcc.make ! make/linux/makefiles/sparcWorks.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/sparcWorks.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/vm.make ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/objectMonitor.hpp Changeset: 2968675b413e Author: stefank Date: 2010-12-02 20:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2968675b413e 7003786: sort Obj_Files before compiling Summary: Reverted to old sort order on Linux and Solaris. Reviewed-by: tonyp, coleenp ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: cb2d0a362639 Author: sla Date: 2010-12-02 05:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cb2d0a362639 6981484: Update development launcher Summary: Add new development launcher called hotspot(.exe) Reviewed-by: coleenp ! make/linux/makefiles/launcher.make ! make/solaris/makefiles/launcher.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make + make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h + src/os/posix/launcher/java_md.c + src/os/posix/launcher/java_md.h + src/os/posix/launcher/launcher.script - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h + src/os/windows/launcher/java_md.c + src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp + src/share/tools/launcher/java.c + src/share/tools/launcher/java.h + src/share/tools/launcher/jli_util.c + src/share/tools/launcher/jli_util.h + src/share/tools/launcher/wildcard.c + src/share/tools/launcher/wildcard.h ! src/share/vm/prims/jvm.h Changeset: 9bc798875b2a Author: coleenp Date: 2010-12-04 00:09 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9bc798875b2a 6704010: Internal Error (src/share/vm/interpreter/interpreterRuntime.cpp:1106) Summary: Fixed a race condition in the assertion caused by an unguarded, concurrent access to a GrowableArray object. Reviewed-by: coleenp, dholmes, dsamersoff Contributed-by: volker.simonis at gmail.com ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 42f65821fa4e Author: coleenp Date: 2010-12-06 15:37 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/42f65821fa4e Merge Changeset: 684faacebf20 Author: kamg Date: 2010-12-06 20:21 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/684faacebf20 7003782: Update JVMTI version to 1.2 for jdk7 Summary: Update minor version to 1.2 for jdk7 Reviewed-by: phh, dcubed ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiH.xsl Changeset: 017cd8bce8a8 Author: sla Date: 2010-12-07 03:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/017cd8bce8a8 6539281: -Xcheck:jni should validate char* argument to ReleaseStringUTFChars Summary: Tag allocated memory with a magic value and verify when releasing. Reviewed-by: phh, stefank ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 401fbd7ff77c Author: kevinw Date: 2010-12-08 04:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/401fbd7ff77c 7003789: PTRACE_GETREGS problems with SA on Linux. Summary: ifdef definitions for PTRACE_GETREGS_REQ clarified Reviewed-by: dholmes ! agent/src/os/linux/ps_proc.c Changeset: 016a3628c885 Author: tonyp Date: 2010-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/016a3628c885 6994056: G1: when GC locker is active, extend the Eden instead of allocating into the old gen Summary: Allow the eden to the expanded up to a point when the GC locker is active. Reviewed-by: jwilhelm, johnc, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3cd116fd11be Author: johnc Date: 2010-12-07 16:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3cd116fd11be 6994628: G1: Test gc/gctests/FinalizeTest05 fails (one live object is finalized) Summary: The Solaris Studio 12 update 1 C++ compiler was incorrectly re-ordering the reads of an object's mark word in oopDesc::forward_to_atomic(). This opened a small window where one thread could execute the successful CAS path even though another thread had already successfully forwarded the object. This could result in an object being copied twice. The code in oopDesc::forward_to_atomic() was changed to read the mark word once. Reviewed-by: ysr, tonyp ! src/share/vm/oops/oop.pcgc.inline.hpp Changeset: 459fad165e5e Author: johnc Date: 2010-12-07 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/459fad165e5e Merge Changeset: 6cd6d394f280 Author: ysr Date: 2010-12-07 21:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6cd6d394f280 7001033: assert(gch->gc_cause() == GCCause::_scavenge_alot || !gch->incremental_collection_failed()) 7002546: regression on SpecJbb2005 on 7b118 comparing to 7b117 on small heaps Summary: Relaxed assertion checking related to incremental_collection_failed flag to allow for ExplicitGCInvokesConcurrent behaviour where we do not want a failing scavenge to bail to a stop-world collection. Parameterized incremental_collection_will_fail() so we can selectively use, or not use, as appropriate, the statistical prediction at specific use sites. This essentially reverts the scavenge bail-out logic to what it was prior to some recent changes that had inadvertently started using the statistical prediction which can be noisy in the presence of bursty loads. Added some associated verbose non-product debugging messages. Reviewed-by: johnc, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp Changeset: 8df09fb45352 Author: ysr Date: 2010-12-09 09:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8df09fb45352 7005259: CMS: BubbleUpRef asserts referent(obj)->is_oop() failed: Enqueued a bad referent Summary: Relaxed the assert by allowing NULL referents when discovery may be concurrent. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: f0ef5f5a460f Author: ysr Date: 2010-12-09 21:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f0ef5f5a460f Merge - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp - src/share/vm/prims/hpi_imported.h ! src/share/vm/runtime/globals.hpp - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 505c913f22f8 Author: trims Date: 2010-12-10 17:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/505c913f22f8 Merge - make/linux/makefiles/makedeps.make - make/solaris/makefiles/makedeps.make - make/windows/README - make/windows/makefiles/makedeps.make - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp - src/share/tools/MakeDeps/ArgsParser.java - src/share/tools/MakeDeps/BuildConfig.java - src/share/tools/MakeDeps/Database.java - src/share/tools/MakeDeps/DirectoryTree.java - src/share/tools/MakeDeps/DirectoryTreeNode.java - src/share/tools/MakeDeps/FileFormatException.java - src/share/tools/MakeDeps/FileList.java - src/share/tools/MakeDeps/FileName.java - src/share/tools/MakeDeps/Macro.java - src/share/tools/MakeDeps/MacroDefinitions.java - src/share/tools/MakeDeps/MakeDeps.java - src/share/tools/MakeDeps/MetroWerksMacPlatform.java - src/share/tools/MakeDeps/Platform.java - src/share/tools/MakeDeps/UnixPlatform.java - src/share/tools/MakeDeps/Util.java - src/share/tools/MakeDeps/WinGammaPlatform.java - src/share/tools/MakeDeps/WinGammaPlatformVC6.java - src/share/tools/MakeDeps/WinGammaPlatformVC7.java - src/share/tools/MakeDeps/WinGammaPlatformVC8.java - src/share/tools/MakeDeps/WinGammaPlatformVC9.java - src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep - src/share/vm/gc_implementation/includeDB_gc_g1 - src/share/vm/gc_implementation/includeDB_gc_parNew - src/share/vm/gc_implementation/includeDB_gc_parallelScavenge - src/share/vm/gc_implementation/includeDB_gc_serial - src/share/vm/gc_implementation/includeDB_gc_shared - src/share/vm/includeDB_compiler1 - src/share/vm/includeDB_compiler2 - src/share/vm/includeDB_core - src/share/vm/includeDB_features - src/share/vm/includeDB_gc - src/share/vm/includeDB_gc_parallel - src/share/vm/includeDB_jvmti - src/share/vm/includeDB_shark - src/share/vm/includeDB_zero - src/share/vm/prims/hpi_imported.h - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 0d4395745860 Author: trims Date: 2010-12-10 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0d4395745860 7006221: Bump the HS20 build number to 04 Summary: Update the HS20 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: af96d06cc0da Author: trims Date: 2010-12-16 20:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/af96d06cc0da Merge Changeset: 5fa559508216 Author: iveresov Date: 2010-12-15 20:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5fa559508216 7007229: Fix warnings with VS2010 in compressedStream.cpp Summary: An interference between a fix for 6993125 and disabled optimization in compressedStream.cpp produces a warning with VS2010. Disable the warning for the code fragment for which the optimizations are disabled. Reviewed-by: kvn ! src/share/vm/code/compressedStream.cpp Changeset: f2da85a9b08e Author: twisti Date: 2010-11-30 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f2da85a9b08e 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM Summary: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic. Reviewed-by: jrose, kvn ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/thread.cpp Changeset: ac637b7220d1 Author: iveresov Date: 2010-11-30 23:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ac637b7220d1 6985015: C1 needs to support compressed oops Summary: This change implements compressed oops for C1 for x64 and sparc. The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR. Compressed oops are now also enabled with tiered. Reviewed-by: twisti, kvn, never, phh ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Defs_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/runtime/arguments.cpp Changeset: dbbf44db0107 Author: iveresov Date: 2010-11-30 23:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dbbf44db0107 Merge Changeset: 4da76e32c0be Author: never Date: 2010-12-01 10:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4da76e32c0be 7002666: eclipse CDT projects crash with compressed oops Reviewed-by: kvn, twisti ! src/share/vm/opto/memnode.cpp + test/compiler/7002666/Test7002666.java Changeset: 0cb042fd2d4b Author: never Date: 2010-12-01 15:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0cb042fd2d4b 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: bbefa3ca1543 Author: twisti Date: 2010-12-02 01:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bbefa3ca1543 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop Reviewed-by: kvn, never ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 5ddfcf4b079e Author: iveresov Date: 2010-12-02 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5ddfcf4b079e 7003554: (tiered) assert(is_null_object() || handle() != NULL) failed: cannot embed null pointer Summary: C1 with profiling doesn't check whether the MDO has been really allocated, which can silently fail if the perm gen is full. The solution is to check if the allocation failed and bailout out of inlining or compilation. Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 2f644f85485d Author: twisti Date: 2010-12-03 01:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2f644f85485d 6961690: load oops from constant table on SPARC Summary: oops should be loaded from the constant table of an nmethod instead of materializing them with a long code sequence. 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/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/vmError_linux.cpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/utilities/debug.cpp Changeset: b856cd7f4e60 Author: twisti Date: 2010-12-03 06:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b856cd7f4e60 7003798: test/compiler/6991596 fails with true != false Summary: The test of 6991596 fails on SPARCV9. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! test/compiler/6991596/Test6991596.java Changeset: 7601ab0e1e33 Author: never Date: 2010-12-03 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7601ab0e1e33 7004530: casx used for 32 bit cas after 7003554 Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: dad31fc330cd Author: jrose Date: 2010-12-03 15:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dad31fc330cd 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 5fe0781a8560 Author: kvn Date: 2010-12-07 11:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5fe0781a8560 7004925: CTW: assert(nbits == 32 || -(1 << nbits-1) <= x && x < ( 1 << nbits-1)) failed: value out of range Summary: Set offset in register if it does not fit 13 bits. Reviewed-by: iveresov ! src/cpu/sparc/vm/sparc.ad Changeset: ec8c74742417 Author: iveresov Date: 2010-12-08 02:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ec8c74742417 7005241: C1: SEGV in java.util.concurrent.LinkedTransferQueue.xfer() with compressed oops Summary: Implementation of the CAS primitive for x64 compressed oops was incorrect. It kills rscratch2 register (r11), which is allocatable in C1. Also, we don't need to restore cmpval as it's never used after that, so we need only one temporary register, which can be scratch1. Reviewed-by: kvn, never ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 4de5f4101cfd Author: iveresov Date: 2010-12-08 17:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4de5f4101cfd Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/thread.cpp Changeset: 79d8657be916 Author: kvn Date: 2010-12-10 14:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/79d8657be916 6993125: runThese crashes with assert(Thread::current()->on_local_stack((address)this)) Summary: add another ResourceObj debug field to distinguish garbage Reviewed-by: dholmes, coleenp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp Changeset: 361783318e7e Author: never Date: 2010-12-13 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/361783318e7e 7004940: CTW: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG Reviewed-by: kvn, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: f9c511aae070 Author: iveresov Date: 2010-12-15 23:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f9c511aae070 Merge Changeset: 642e54d1850a Author: dsamersoff Date: 2010-12-09 17:53 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/642e54d1850a 6989076: JVM crashes in klassItable::initialize_itable_for_interface Summary: hotspot should check protection attribute besides the name and signature of the method when constructing vtable. Reviewed-by: dcubed ! src/share/vm/oops/klassVtable.cpp Changeset: 09b4dd4f152b Author: kamg Date: 2010-12-09 15:04 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09b4dd4f152b 7004582: Add GetThisObject() function to JVMTI 1.2 Summary: Add 'GetThisObject' function Reviewed-by: never, coleenp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe_hp.cpp Changeset: a5610f0862fe Author: dholmes Date: 2010-12-09 20:12 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a5610f0862fe 7005007: Refine use of ALT_COMPILER_PATH to avoid conflict with JPRT usage Summary: Check for CROSS_COMPILE_ARCH being set as an indicator to use ALT_COMPILER_PATH Reviewed-by: acorn, ohair ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/gcc.make Changeset: 7cf1a74771e8 Author: coleenp Date: 2010-12-10 12:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7cf1a74771e8 6988439: Parallel Class Loading test deadlock involving MethodData_lock and Pending List Lock Summary: Don't acquire methodData_lock while holding pending list lock Reviewed-by: kvn, never, ysr ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/methodOop.cpp Changeset: 2d4762ec74af Author: zgu Date: 2010-12-11 13:20 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2d4762ec74af 7003748: Decode C stack frames when symbols are presented (PhoneHome project) Summary: Implemented in-process C native stack frame decoding when symbols are available. Reviewed-by: coleenp, never ! make/solaris/makefiles/vm.make + src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp + src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp + src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/frame.cpp + src/share/vm/utilities/decoder.cpp + src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/elfFile.cpp + src/share/vm/utilities/elfFile.hpp + src/share/vm/utilities/elfStringTable.cpp + src/share/vm/utilities/elfStringTable.hpp + src/share/vm/utilities/elfSymbolTable.cpp + src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 54f5dd2aa1d9 Author: zgu Date: 2010-12-11 13:46 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/54f5dd2aa1d9 Merge ! make/solaris/makefiles/vm.make - src/os/linux/launcher/java.c - src/os/linux/launcher/java.h - src/os/linux/launcher/java_md.c - src/os/linux/launcher/java_md.h - src/os/linux/vm/hpi_linux.cpp - src/os/linux/vm/hpi_linux.hpp ! src/os/linux/vm/os_linux.cpp - src/os/solaris/launcher/java.c - src/os/solaris/launcher/java.h - src/os/solaris/launcher/java_md.c - src/os/solaris/launcher/java_md.h - src/os/solaris/vm/hpi_solaris.cpp - src/os/solaris/vm/hpi_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp - src/os/windows/vm/hpi_windows.cpp - src/os/windows/vm/hpi_windows.hpp ! src/os/windows/vm/os_windows.cpp - src/share/vm/prims/hpi_imported.h ! src/share/vm/runtime/frame.cpp - src/share/vm/runtime/hpi.cpp - src/share/vm/runtime/hpi.hpp Changeset: 06ba96862949 Author: coleenp Date: 2010-12-13 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/06ba96862949 Merge Changeset: b03e6b4c7c75 Author: coleenp Date: 2010-12-14 15:10 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b03e6b4c7c75 7006471: fix for 6988439 crashes when pending list lock is null Summary: missing null check in owns_pending_list_lock() because this can be called before pending_list_lock is initialized. Reviewed-by: never, kvn ! src/share/vm/oops/instanceRefKlass.cpp Changeset: e7ad5f6f4d29 Author: stefank Date: 2010-12-15 05:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7ad5f6f4d29 7006659: temporary adlc files are added to the build variables Summary: Don't recurse into sub-directories when looking for source files. Reviewed-by: never, brutisso ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh Changeset: aa6e219afbf1 Author: sla Date: 2010-12-15 07:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aa6e219afbf1 7006354: Updates to Visual Studio project creation and development launcher Summary: Updates to Visual Studio project creation and development launcher Reviewed-by: stefank, coleenp ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! make/windows/build_vm_def.sh ! make/windows/create.bat ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! make/windows/projectfiles/compiler1/Makefile ! make/windows/projectfiles/compiler1/vm.def ! make/windows/projectfiles/compiler2/Makefile ! make/windows/projectfiles/compiler2/vm.def ! make/windows/projectfiles/core/Makefile ! make/windows/projectfiles/core/vm.def ! make/windows/projectfiles/kernel/Makefile ! make/windows/projectfiles/kernel/vm.def ! make/windows/projectfiles/tiered/Makefile ! make/windows/projectfiles/tiered/vm.def ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script ! src/os/windows/launcher/java_md.c ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC6.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC8.java ! src/share/tools/launcher/java.c ! src/share/tools/launcher/jli_util.c Changeset: 450ece4d8a10 Author: sla Date: 2010-12-15 08:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/450ece4d8a10 Merge Changeset: 6ce496c8fc07 Author: coleenp Date: 2010-12-16 09:31 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6ce496c8fc07 Merge Changeset: fb712ff22571 Author: tonyp Date: 2010-12-14 16:19 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fb712ff22571 7000559: G1: assertion failure !outer || (full_collections_started == _full_collections_completed + 1) Summary: The concurrent marking thread can complete its operation and increment the full GC counter during a Full GC. This causes the nesting of increments to the start and end of Full GCs that we are expecting to be wrong. the fix is for the marking thread to join the suspendible thread set before incrementing the counter so that it's blocked until the Full GC (or any other safepoint) is finished. The change also includes some minor code cleanup (I renamed a parameter). Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 36eef023306f Author: ysr Date: 2010-12-16 09:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/36eef023306f Merge Changeset: 320ef6401fce Author: ysr Date: 2010-12-16 12:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/320ef6401fce Merge Changeset: 03e1b9fce89d Author: dholmes Date: 2010-12-16 20:57 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/03e1b9fce89d 7003707: need to remove (some) system include files from the HotSpot header files Summary: move socket_available into os_linux.cpp to avoid inclusion of ioctl.h in os_linux.inline.hpp Reviewed-by: coleenp, stefank, ikrylov ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp Changeset: 9669f9b28410 Author: trims Date: 2010-12-16 20:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9669f9b28410 Merge Changeset: 08b76f57574b Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/08b76f57574b Added tag jdk7-b123 for changeset 9669f9b28410 ! .hgtags From lana.steuck at oracle.com Thu Dec 23 16:54:42 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 16:54:42 +0000 Subject: hg: jdk7/tl/jaxp: 7 new changesets Message-ID: <20101223165442.D08A4476A4@hg.openjdk.java.net> Changeset: ced66f2b52cf Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ced66f2b52cf Added tag jdk7-b122 for changeset 03ff13d19c8f ! .hgtags Changeset: 68ef5e4375d5 Author: ohair Date: 2010-12-03 08:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/68ef5e4375d5 Merge Changeset: f810d59bcc3a Author: ohair Date: 2010-12-15 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/f810d59bcc3a Merge Changeset: 4af8ef0521e3 Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/4af8ef0521e3 Merge Changeset: e2aedea6495d Author: lana Date: 2010-12-20 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/e2aedea6495d Merge Changeset: a5de4610febf Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/a5de4610febf Added tag jdk7-b123 for changeset e2aedea6495d ! .hgtags Changeset: ce7b69a2d927 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ce7b69a2d927 Merge From lana.steuck at oracle.com Thu Dec 23 16:54:47 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 16:54:47 +0000 Subject: hg: jdk7/tl/jaxws: 7 new changesets Message-ID: <20101223165447.F0461476A5@hg.openjdk.java.net> Changeset: f74fc1dbef46 Author: cl Date: 2010-12-16 18:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/f74fc1dbef46 Added tag jdk7-b122 for changeset 17b6c48a3449 ! .hgtags Changeset: 0f117d4f6847 Author: ohair Date: 2010-12-03 08:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/0f117d4f6847 Merge Changeset: a5fc960570f6 Author: ohair Date: 2010-12-15 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/a5fc960570f6 Merge Changeset: 2518d26fa43c Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/2518d26fa43c Merge Changeset: 5a8e43bcce56 Author: lana Date: 2010-12-20 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/5a8e43bcce56 Merge Changeset: 764fec69c128 Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/764fec69c128 Added tag jdk7-b123 for changeset 5a8e43bcce56 ! .hgtags Changeset: 8ac759987b08 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8ac759987b08 Merge From lana.steuck at oracle.com Thu Dec 23 16:59:59 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 16:59:59 +0000 Subject: hg: jdk7/tl/jdk: 76 new changesets Message-ID: <20101223171205.0591A476A7@hg.openjdk.java.net> Changeset: e8ef99adf42b Author: cl Date: 2010-12-16 18:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8ef99adf42b Added tag jdk7-b122 for changeset ac311eb325bf ! .hgtags Changeset: beb9f3298ad3 Author: andrew Date: 2010-11-23 02:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/beb9f3298ad3 7000225: Sanity check on sane-alsa-headers is broken Summary: Fix use of tab separators, ${alsa_version} expansion and conditional Reviewed-by: ohair ! make/common/shared/Sanity.gmk Changeset: fd6873594ae2 Author: ohair Date: 2010-11-30 17:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd6873594ae2 6987107: Add variable to add to but not modify non-fcs version string Reviewed-by: jcoomes, dholmes, andrew, kvn ! make/common/shared/Defs.gmk ! make/jprt.gmk Changeset: 9a976162a702 Author: ohair Date: 2010-12-03 08:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9a976162a702 Merge Changeset: 3ead3b641162 Author: ohair Date: 2010-12-03 21:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3ead3b641162 Merge Changeset: 5e54a0a879e8 Author: mfang Date: 2010-11-30 22:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e54a0a879e8 6675400: "Details" in English has to be "Details" in German Reviewed-by: yhuang ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties Changeset: dd9dbdf2c508 Author: mfang Date: 2010-12-02 14:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd9dbdf2c508 6851050: unnecessary full stop character in ja jdi messages Reviewed-by: ogino ! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties Changeset: e3ecd9555ff0 Author: yhuang Date: 2010-12-02 02:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e3ecd9555ff0 6925851: Localize JRE into pt_BR Reviewed-by: mfang, psun ! make/common/Defs.gmk ! make/java/util/FILES_java.gmk + src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties + src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties + src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties + src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties + src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties + src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties + src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties + src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties + src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java + src/share/classes/sun/awt/resources/awt_pt_BR.properties + src/share/classes/sun/launcher/resources/launcher_pt_BR.properties + src/share/classes/sun/management/resources/agent_pt_BR.properties + src/share/classes/sun/misc/resources/Messages_pt_BR.java + src/share/classes/sun/print/resources/serviceui_pt_BR.properties + src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties + src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties + src/share/classes/sun/security/util/AuthResources_pt_BR.java + src/share/classes/sun/security/util/Resources_pt_BR.java + src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties + src/share/classes/sun/util/logging/resources/logging_pt_BR.properties + src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java + src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties ! src/windows/native/sun/jkernel/kernel.rc + src/windows/native/sun/jkernel/kernel_pt_BR.rc Changeset: 65a17e71c12e Author: yhuang Date: 2010-12-02 20:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/65a17e71c12e Merge Changeset: 750150b298fc Author: mfang Date: 2010-12-03 17:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/750150b298fc 6566218: l10n of 6476932 Reviewed-by: yhuang ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java Changeset: 4f5e4145da23 Author: mfang Date: 2010-12-03 17:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f5e4145da23 6579775: l10n update after 6212566 Reviewed-by: yhuang ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: 9eaf28c91567 Author: mfang Date: 2010-12-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9eaf28c91567 6708417: On Chinese OS Applet string is appearing in English Reviewed-by: yhuang ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java Changeset: 2f7a3aae0331 Author: mfang Date: 2010-12-03 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2f7a3aae0331 6745048: Unnecessary surfix "(O)" in JFileChooser open button text Reviewed-by: yhuang ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties Changeset: e31ac89c72ce Author: mfang Date: 2010-12-03 17:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e31ac89c72ce 6785462: Missing "(O)" in JFileChooser Open button in Windows LAF Reviewed-by: yhuang ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties Changeset: 5b1b2c521874 Author: mfang Date: 2010-12-03 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5b1b2c521874 6896693: [fr] keytool: wrong message format in fr locale Reviewed-by: yhuang ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java Changeset: 35b2227806bc Author: mfang Date: 2010-12-05 17:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/35b2227806bc 7000729: NLS: rmic.properties cannot be processed by translation team Reviewed-by: ogino ! src/share/classes/sun/rmi/rmic/resources/rmic.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties Changeset: 66117705c085 Author: mfang Date: 2010-12-05 18:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66117705c085 7004706: l10n of 7000752 Duplicate entry in RowSetResourceBundles.properties Reviewed-by: ogino ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties Changeset: 8f2965949d36 Author: mfang Date: 2010-12-05 18:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8f2965949d36 Merge Changeset: bc577ec0d3d1 Author: ohair Date: 2010-12-06 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc577ec0d3d1 7001720: copyright templates not rebranded Reviewed-by: mchung ! make/templates/bsd-header ! make/templates/gpl-cp-header ! make/templates/gpl-header Changeset: b99b1789dc4c Author: ohair Date: 2010-12-13 10:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b99b1789dc4c Merge Changeset: 27be4ed38e97 Author: ohair Date: 2010-12-15 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/27be4ed38e97 Merge ! make/common/Defs.gmk ! make/common/shared/Sanity.gmk ! src/share/classes/com/sun/rowset/RowSetResourceBundle.properties Changeset: 12da5e10cab8 Author: ohair Date: 2010-12-16 19:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/12da5e10cab8 Merge Changeset: 435b477c4f14 Author: ohair Date: 2010-12-18 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/435b477c4f14 6909026: Change GNU make version requirement to 3.81 Reviewed-by: robilad ! make/common/shared/Defs-versions.gmk Changeset: 024fe931de8c Author: lana Date: 2010-12-03 17:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/024fe931de8c Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 15e3f6f4a433 Author: bae Date: 2010-12-05 15:51 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15e3f6f4a433 6980281: SWAT: SwingSet2 got core dumped in Solaris-AMD64 using b107 swat build Reviewed-by: prr, ohair ! make/common/Defs-solaris.gmk ! make/common/shared/Compiler-sun.gmk Changeset: 1d4340015b85 Author: srl Date: 2010-12-06 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1d4340015b85 6886358: layout code update Reviewed-by: igor, prr ! make/sun/font/FILES_c.gmk ! src/share/classes/sun/font/FontUtilities.java ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h + src/share/native/sun/font/layout/HangulLayoutEngine.cpp + src/share/native/sun/font/layout/HangulLayoutEngine.h - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h + src/share/native/sun/font/layout/ICUFeatures.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h + src/share/native/sun/font/layout/TibetanLayoutEngine.cpp + src/share/native/sun/font/layout/TibetanLayoutEngine.h + src/share/native/sun/font/layout/TibetanReordering.cpp + src/share/native/sun/font/layout/TibetanReordering.h + test/java/awt/font/TextLayout/TestOldHangul.java + test/java/awt/font/TextLayout/TestTibetan.java Changeset: 47cd69eff641 Author: flar Date: 2010-12-06 21:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47cd69eff641 6775317: Improve performance of non-AA transformed rectangles and single wide lines in software pipelines Reviewed-by: jgodinez, prr ! make/sun/awt/Depend.mak ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-vers ! src/share/classes/sun/java2d/SurfaceData.java + src/share/classes/sun/java2d/loops/DrawParallelogram.java + src/share/classes/sun/java2d/loops/FillParallelogram.java ! src/share/classes/sun/java2d/loops/RenderLoops.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/native/sun/java2d/loops/Any3Byte.c ! src/share/native/sun/java2d/loops/Any4Byte.c ! src/share/native/sun/java2d/loops/AnyByte.c ! src/share/native/sun/java2d/loops/AnyInt.c ! src/share/native/sun/java2d/loops/AnyShort.c + src/share/native/sun/java2d/loops/DrawParallelogram.c + src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/LoopMacros.h ! src/solaris/native/sun/java2d/loops/java2d_Mlib.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c Changeset: ad7feec4413e Author: miroslawzn Date: 2010-12-08 15:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ad7feec4413e 6813208: pageDialog throws NPE from applet Reviewed-by: ant, minqi ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java Changeset: 90dcea60577e Author: miroslawzn Date: 2010-12-08 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90dcea60577e 6859086: Dialog created by JOptionPane.showMessageDialog does not repaint sometimes Reviewed-by: bae, chrisphi ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h Changeset: 2dff913337a8 Author: lana Date: 2010-12-09 21:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2dff913337a8 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 0eeac8ca33e3 Author: prr Date: 2010-12-10 16:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0eeac8ca33e3 7005896: Java2D D3D pipeline doesn't recognise latest Windows OSes Reviewed-by: bae, jgodinez ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h Changeset: 23a3e724ee9d Author: dav Date: 2010-12-01 14:43 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23a3e724ee9d 6709453: (dav)Screen flickers when a JFrame switches to fullscreen mode Reviewed-by: art, dcherepanov ! src/windows/classes/sun/awt/Win32GraphicsDevice.java Changeset: 386b49abc195 Author: denis Date: 2010-12-01 17:25 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/386b49abc195 6945178: SecurityException upon drag-and-drop Summary: A flag added to distinguish drop action handling. Reviewed-by: uta, art ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: df99592ad34f Author: dav Date: 2010-12-02 19:53 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df99592ad34f 7002173: java.awt package docs build warnings Reviewed-by: ant ! src/share/classes/java/awt/SecondaryLoop.java Changeset: 786f42385034 Author: dmeetry Date: 2010-12-04 02:27 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/786f42385034 6578041: Drag & Drop from Motif to Java does not work. Summary: fixing java's interpretation of unsigned 32bit int as signed during an implicit conversion to 64bit int. Reviewed-by: denis, chrisphi ! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java Changeset: 4bfe9244ede4 Author: lana Date: 2010-12-03 11:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4bfe9244ede4 Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: df3aeffb636e Author: lana Date: 2010-12-03 17:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df3aeffb636e Merge Changeset: 2383ded24c27 Author: dcherepanov Date: 2010-12-07 21:02 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2383ded24c27 6984049: applet browser vendor rebranding changes (jdk7 only) Reviewed-by: art ! src/share/classes/sun/applet/Main.java Changeset: e9018c697557 Author: lana Date: 2010-12-13 16:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9018c697557 Merge Changeset: 6bb0d3464928 Author: rupashka Date: 2010-12-02 15:54 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6bb0d3464928 6639507: Title of javax.swing.JDialog is null while spec says it's empty Reviewed-by: alexp ! src/share/classes/java/awt/Dialog.java ! src/share/classes/javax/swing/JDialog.java + test/javax/swing/JDialog/6639507/bug6639507.java Changeset: 95159bdba902 Author: rupashka Date: 2010-12-02 18:02 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95159bdba902 6988205: Test failed due to compilation failed, JTextComponent doesn't create drop locations with null bias. Reviewed-by: alexp + test/javax/swing/DataTransfer/6456844/bug6456844.java Changeset: 3122d9afafd5 Author: okutsu Date: 2010-12-08 12:50 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3122d9afafd5 4396385: [Fmt-Da] SimpleDateFormat too lenient when parsing 1-based hours Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug4396385.java Changeset: 35c13e43bbf3 Author: okutsu Date: 2010-12-08 13:02 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/35c13e43bbf3 6203034: [AC] AttributedCharacterIterator methods works wrong (run with respect differs from spec) Reviewed-by: peytoia ! src/share/classes/java/text/AttributedCharacterIterator.java Changeset: eff36d0a0615 Author: okutsu Date: 2010-12-08 13:09 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eff36d0a0615 6653944: (cal) BuddhistCalendar yearOffset erased when deserialized Reviewed-by: peytoia ! src/share/classes/sun/util/BuddhistCalendar.java + test/sun/util/calendar/Bug6653944.java Changeset: 230822c90868 Author: okutsu Date: 2010-12-08 18:05 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/230822c90868 6457726: Character.isWhitespace JavaDoc has nonexistent char literals Reviewed-by: peytoia ! src/share/classes/java/lang/Character.java Changeset: 07f5669f1231 Author: naoto Date: 2010-12-08 15:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07f5669f1231 6647615: Sample code in ListResourceBundle is not correct and causes a compile error. Reviewed-by: peytoia ! src/share/classes/java/util/ListResourceBundle.java Changeset: 4c10246b3f62 Author: okutsu Date: 2010-12-09 12:36 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c10246b3f62 6911839: Sles/SuSE 11 needs CJK support Reviewed-by: peytoia ! make/sun/awt/Makefile Changeset: ea504a083acd Author: naoto Date: 2010-12-09 15:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea504a083acd 7000507: javadoc warnings in java.util.Locale 7004335: Javadoc for Locale.toLangaugeTag() is unclear 7005320: (lc) doc: missing " in Locale.forLanguageTag code samples Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java Changeset: eb78026c92a9 Author: naoto Date: 2010-12-09 11:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb78026c92a9 6486695: [Col] Doc: CollationElementIterator example assumes Collator.getInstance return type Reviewed-by: okutsu ! src/share/classes/java/text/CollationElementIterator.java Changeset: 71d76815eba6 Author: naoto Date: 2010-12-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/71d76815eba6 Merge Changeset: 7e8acb2a9259 Author: peytoia Date: 2010-12-10 11:43 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e8acb2a9259 6515695: [Col] java.text.RuleBasedCollator - JavaDoc "Examples" - Two bugs in sample code Reviewed-by: okutsu ! src/share/classes/java/text/RuleBasedCollator.java Changeset: 11b73cda876d Author: lana Date: 2010-12-10 14:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/11b73cda876d Merge ! src/share/classes/java/awt/Dialog.java - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 97e54a18d599 Author: naoto Date: 2010-12-13 13:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97e54a18d599 7002320: Locale.forLanguageTag()/toLanguageTag() not working properly with ja_JP_JP locale Reviewed-by: dougfelt ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: 0df2e740bd4e Author: lana Date: 2010-12-13 16:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0df2e740bd4e Merge Changeset: 9cc67a600965 Author: lana Date: 2010-12-13 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cc67a600965 Merge - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java Changeset: 550a81304d04 Author: lana Date: 2010-12-20 21:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/550a81304d04 Merge ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h Changeset: 19c125efeda3 Author: jrose Date: 2010-10-30 21:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/19c125efeda3 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Summary: JDK changes which run atop the corresponding JVM hook Reviewed-by: never, twisti ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/InvokeGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/util/ValueConversions.java + test/java/dyn/InvokeGenericTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: 45f5055dd53f Author: jrose Date: 2010-10-30 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45f5055dd53f 6981777: implement JSR 292 EG adjustments from summer 2010 Reviewed-by: twisti - src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/JavaMethodHandle.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! src/share/classes/sun/dyn/util/Wrapper.java ! test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamples.java + test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: f50d2c66f585 Author: jrose Date: 2010-11-22 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f50d2c66f585 6979327: method handle invocation should use casts instead of type parameters to specify return type Summary: Change result type parameters to result type casts. (Also, replace private placeholder class InvokeDynamic.) Reviewed-by: twisti ! make/java/dyn/Makefile + src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! test/java/dyn/InvokeGenericTest.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: 32d6d7a39220 Author: jrose Date: 2010-12-02 02:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/32d6d7a39220 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute Reviewed-by: twisti ! src/share/classes/java/dyn/package-info.java Changeset: a451f7948ec5 Author: jrose Date: 2010-12-02 02:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a451f7948ec5 7001423: JSR 292 bytecode enhancements need unit tests Reviewed-by: twisti + test/java/dyn/InvokeDynamicPrintArgs.java + test/java/dyn/indify/Indify.java Changeset: 6a0245a8f714 Author: jrose Date: 2010-12-02 03:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6a0245a8f714 Merge - make/common/Rules-SCCS.gmk - src/share/classes/com/sun/media/sound/MidiDeviceReceiver.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/share/native/sun/java2d/cmm/lcms/cmscam97.c - src/share/native/sun/java2d/cmm/lcms/cmsmatsh.c - src/share/native/sun/java2d/cmm/lcms/icc34.h - src/share/native/sun/java2d/cmm/lcms/lcms.h - src/solaris/classes/sun/net/spi/SdpProvider.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java - src/solaris/native/sun/net/spi/SdpProvider.c - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java - test/java/util/Locale/data/deflocale.exe - test/java/util/Locale/data/deflocale.jds3 - test/java/util/Locale/data/deflocale.rhel4 - test/java/util/Locale/data/deflocale.winvista - test/java/util/Locale/data/deflocale.winxp - test/sun/net/www/http/ChunkedInputStream/ChunkedCharEncoding.sh - test/tools/launcher/VerifyExceptions.java Changeset: 7fc85363b44c Author: jrose Date: 2010-12-03 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fc85363b44c Merge Changeset: 0db159ce2517 Author: jrose Date: 2010-12-16 00:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0db159ce2517 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 75040738aec9 Author: jrose Date: 2010-12-16 15:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75040738aec9 7001424: implement JSR 292 EG adjustments, November 2010 Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ClassValue.java ! src/share/classes/java/dyn/ConstantCallSite.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/MutableCallSite.java + src/share/classes/java/dyn/Switcher.java ! src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/package-info.java ! test/java/dyn/ClassValueTest.java ! test/java/dyn/InvokeDynamicPrintArgs.java ! test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: 04c9b38d6bf3 Author: trims Date: 2010-12-16 20:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/04c9b38d6bf3 Merge - src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - test/java/dyn/JavaDocExamples.java Changeset: 2dbd18b83bad Author: trims Date: 2010-12-21 16:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2dbd18b83bad Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - test/java/dyn/JavaDocExamples.java Changeset: cbf9f3826c2d Author: igor Date: 2010-11-30 09:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cbf9f3826c2d Merge - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 7fb84fe35a93 Author: igor Date: 2010-12-06 00:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fb84fe35a93 Merge Changeset: 22b7781ad25a Author: igor Date: 2010-12-08 01:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/22b7781ad25a Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: e7972f7e82d1 Author: herrick Date: 2010-12-12 22:58 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7972f7e82d1 Merge Changeset: 1124ac162f32 Author: herrick Date: 2010-12-20 13:15 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1124ac162f32 Merge Changeset: 36898b974d28 Author: igor Date: 2010-12-21 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/36898b974d28 Merge - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h Changeset: 869190935eed Author: igor Date: 2010-12-21 18:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/869190935eed Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - test/java/dyn/JavaDocExamples.java Changeset: 83480217896c Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83480217896c Added tag jdk7-b123 for changeset 869190935eed ! .hgtags Changeset: 6acd81baf2c7 Author: lana Date: 2010-12-22 23:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6acd81baf2c7 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/util/ListResourceBundle.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java From lana.steuck at oracle.com Thu Dec 23 17:14:17 2010 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 23 Dec 2010 17:14:17 +0000 Subject: hg: jdk7/tl/langtools: 8 new changesets Message-ID: <20101223171431.97412476A8@hg.openjdk.java.net> Changeset: 9968ce958706 Author: cl Date: 2010-12-16 18:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9968ce958706 Added tag jdk7-b122 for changeset 11e7b4c0476e ! .hgtags Changeset: 4f086529d05c Author: mfang Date: 2010-12-03 20:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4f086529d05c 6522789: [zh_CN] translation of "enclosing class" in doclet is incorrect Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties Changeset: d9deecf9181b Author: mfang Date: 2010-12-05 18:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d9deecf9181b Merge Changeset: a0331c79cea9 Author: ohair Date: 2010-12-15 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a0331c79cea9 Merge Changeset: 98570f7ba610 Author: ohair Date: 2010-12-16 19:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/98570f7ba610 Merge Changeset: a3b5b531542a Author: lana Date: 2010-12-20 21:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a3b5b531542a Merge - src/share/classes/com/sun/tools/apt/main/JavaCompiler.java - src/share/classes/com/sun/tools/doclets/formats/html/StylesheetWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java - test/tools/javac/diags/examples/VarargsFilename.java - test/tools/javac/diags/examples/VarargsFilenameAdditional.java - test/tools/javac/diags/examples/VarargsPlural/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPlural/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsFilename.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPlural.java - test/tools/javac/diags/examples/VarargsPluralAdditional/VarargsPluralAdditional.java Changeset: 659417e931fe Author: cl Date: 2010-12-22 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/659417e931fe Added tag jdk7-b123 for changeset a3b5b531542a ! .hgtags Changeset: 8859e49909e6 Author: lana Date: 2010-12-22 23:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8859e49909e6 Merge From jim.holmlund at sun.com Thu Dec 23 18:11:21 2010 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 23 Dec 2010 18:11:21 +0000 Subject: hg: jdk7/tl/langtools: 7008869: Debug printlns accidentally added to make/build.xml Message-ID: <20101223181123.3EB4A476B1@hg.openjdk.java.net> Changeset: dd38bab326a3 Author: jjh Date: 2010-12-23 10:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd38bab326a3 7008869: Debug printlns accidentally added to make/build.xml Summary: Delete bogus echo statements Reviewed-by: ksrini ! make/build.xml From mike.duigou at oracle.com Thu Dec 23 19:46:14 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 23 Dec 2010 11:46:14 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D131E2B.1080702@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> Message-ID: I have updated the webrev with the javadoc changes (identical to below) and Ulf's suggested code changes: http://cr.openjdk.java.net/~mduigou/6728865.3/webrev/ Mike On Dec 23 2010, at 02:02 , Chris Hegarty wrote: > Mike, > > I'm happy with the latest wording, it looks much better. > > -Chris. > > On 23/12/2010 01:23, Mike Duigou wrote: >> Here's another try that tries to use similar wording to Collection: >> * >> *

Care must also be exercised when using collections that have >> * restrictions on the elements that they may contain. Collection >> * implementations are allowed to throw exceptions for any operation >> * involving elements they deem ineligible. For absolute safety the >> * specified collections should contain only elements which are >> * eligible elements for both collections. >> >> And for the throws: >> >> * @throws NullPointerException if either collection is {@code null}. >> * @throws NullPointerException if one collection contains a {@code null} >> * element and {@code null} is not an eligible element for the other collection. >> * (optional) >> * @throws ClassCastException if one collection contains an element that is >> * of a type which is ineligible for the other collection. (optional) >> From mike.duigou at oracle.com Thu Dec 23 20:29:03 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 23 Dec 2010 12:29:03 -0800 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D078824.5030307@oracle.com> References: <4D078824.5030307@oracle.com> Message-ID: Feedback is on webrev.02 http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ : * PrintStream - .flush(), close(), most println() methods synchronize on this for their entire implementation. They could just be made synchronized methods. - The javadoc for append(CharSequence,int,int) for the csq==null condition seems misleading as start and end are considered. * Formatter - The zero params constructor could just call this((Apppendable) null). The advantage is that the StringBuilder is only constructed in one place. - The Formatter(Locale) constructor could just call this(l, (Apppendable) null). Same reason. On Dec 14 2010, at 07:07 , Chris Hegarty wrote: > Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and java.util.Formatter multi-arg constructors that take a java.io.File or String filename (as well as one or more additional args) opens a FileIn/OutputStream to the given File/filename. If one of the other given args causes the constructor to fail ( null or unsupported charset for example ) the FileIn/OutputStream is never closed, and the application does not have a reference to it. You rely on the finalizer to close the stream. > > This is most serious on Windows because you cannot remove a file if there is an open handle to it. > > I also cleaned up an existing regression test that fails in samevm mode (partly) because of this. And removed another excluded test from the list since its bug was fixed some time ago. > > Webrev: > http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ > > -Chris. From Ulf.Zibis at gmx.de Thu Dec 23 21:24:03 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 23 Dec 2010 22:24:03 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> Message-ID: <4D13BDF3.7030000@gmx.de> Am 23.12.2010 20:46, schrieb Mike Duigou: > I have updated the webrev with the javadoc changes (identical to below) and Ulf's suggested code changes: > > http://cr.openjdk.java.net/~mduigou/6728865.3/webrev/ Thanks, I could convince you mostly. But, IMO, the inner comments are too expatiated ("less than O(N/2)" is used 3 times). Aren't the explanation comments from my last example clear enough and more fluently readable? You use "ceiling(n/2)". Didn't you mean "ceiling O(N/2)" for consistence? "//than mere Collection's,iterate on c2." 2 spaces are missing "// One (or both) collections is/are empty. Nothing will match." Shorter: "// At least one collection is empty. Nothing will match." Javadoc: - the term '@throws NullPointerException' is duplicated, don't know if that would work ? - there is a habit, maybe a rule, to insert 2 spaces after '.' -Ulf From kumar.x.srinivasan at oracle.com Thu Dec 23 21:56:05 2010 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 23 Dec 2010 21:56:05 +0000 Subject: hg: jdk7/tl/jdk: 7002386: (launcher) fix XshowSettings Message-ID: <20101223215614.8514B476C9@hg.openjdk.java.net> Changeset: 5beec82bf20d Author: ksrini Date: 2010-12-23 13:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5beec82bf20d 7002386: (launcher) fix XshowSettings Reviewed-by: darcy, mchung, naoto ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Settings.java From Ulf.Zibis at gmx.de Thu Dec 23 22:02:58 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 23 Dec 2010 23:02:58 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D13BDF3.7030000@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> Message-ID: <4D13C712.3040809@gmx.de> Am 23.12.2010 22:24, schrieb Ulf Zibis: > Aren't the explanation comments from my last example clear enough and more fluently readable? For clarification: // collections to iterate and examine containment on Collection iterate = c1; Collection contains = c2; // performance optimization cases if (c1 instanceof Set) { // As mere Collection's contains() impl predictably performs worse // than Set's (< O(N/2)), iterate on c2. iterate = c2; contains = c1; } else if (!(c2 instanceof Set)) { // Both are mere collections. int c1size = c1.size(); int c2size = c2.size(); if (c1size == 0 || c2size == 0) { // At least one collection is empty. Nothing will match. return true; } else if (c1size > c2size) { // Iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires ceiling O(N/2) comparisons then // checking for all c1 elements in c2 would require 75 comparisons // vs. all c2 elements in c1 would require 100. iterate = c2; contains = c1; } } -Ulf From Ulf.Zibis at gmx.de Thu Dec 23 22:24:31 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 23 Dec 2010 23:24:31 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D13BDF3.7030000@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> Message-ID: <4D13CC1F.6030704@gmx.de> Am 23.12.2010 22:24, schrieb Ulf Zibis: > Aren't the explanation comments from my last example clear enough and more fluently readable? Shouldn't we examine the size at first? : // collections to iterate and examine containment on Collection iterate = c1; Collection contains = c2; // performance optimization cases int c1size = c1.size(); int c2size = c2.size(); if (c1size == 0 || c2size == 0) { // At least one collection is empty. Nothing will match. return true; if (c1 instanceof Set || (!(c2 instanceof Set) && c1size > c2size) { // As mere Collection's contains() impl predictably performs worse // than Set's (< O(N/2)), iterate on c2. // Or if both are mere collections, iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires ceiling O(N/2) comparisons then // checking for all c1 elements in c2 would require 75 comparisons // vs. all c2 elements in c1 would require 100. iterate = c2; contains = c1; } -Ulf From jim.holmlund at sun.com Thu Dec 23 20:31:07 2010 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 23 Dec 2010 20:31:07 +0000 Subject: hg: jdk7/tl/langtools: 6982992: Tests CheckAttributedTree.java, JavacTreeScannerTest.java, and SourceTreeeScannerTest.java timeout Message-ID: <20101223203109.915F0476C2@hg.openjdk.java.net> Changeset: e8719f95f2d0 Author: jjh Date: 2010-12-23 12:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e8719f95f2d0 6982992: Tests CheckAttributedTree.java, JavacTreeScannerTest.java, and SourceTreeeScannerTest.java timeout Summary: Hoist some invariant code out of a loop Reviewed-by: ksrini ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java From pbenedict at apache.org Thu Dec 23 22:59:14 2010 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 23 Dec 2010 16:59:14 -0600 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D13CC1F.6030704@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> Message-ID: Ulf, a previous email by Remi said only to invoke size() if the collection is a Set. Paul On Thu, Dec 23, 2010 at 4:24 PM, Ulf Zibis wrote: > Am 23.12.2010 22:24, schrieb Ulf Zibis: > >> Aren't the explanation comments from my last example clear enough and more >> fluently readable? >> > > Shouldn't we examine the size at first? : > > > // collections to iterate and examine containment on > Collection iterate = c1; > Collection contains = c2; > > // performance optimization cases > int c1size = c1.size(); > int c2size = c2.size(); > if (c1size == 0 || c2size == 0) { > // At least one collection is empty. Nothing will match. > return true; > if (c1 instanceof Set || (!(c2 instanceof Set) && c1size > c2size) { > > // As mere Collection's contains() impl predictably performs > worse > // than Set's (< O(N/2)), iterate on c2. > // Or if both are mere collections, iterate over smaller > collection. > > // E.g. if c1 contains 3 elements and c2 contains 50 elements > and > // assuming contains() requires ceiling O(N/2) comparisons then > // checking for all c1 elements in c2 would require 75 > comparisons > // vs. all c2 elements in c1 would require 100. > iterate = c2; > contains = c1; > } > > -Ulf > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Dec 24 16:48:57 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 24 Dec 2010 16:48:57 +0000 Subject: hg: jdk7/tl/jdk: 7005984: 3/3 Incorrect values of S0C and S0CMX appear with -gcnewcapacity in jstat Message-ID: <20101224164917.0D26C47715@hg.openjdk.java.net> Changeset: 3c4afaacd345 Author: dcubed Date: 2010-12-23 23:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c4afaacd345 7005984: 3/3 Incorrect values of S0C and S0CMX appear with -gcnewcapacity in jstat Summary: Swap S0C and S0CMX column values. Reviewed-by: ohair, dholmes, poonam ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcNewCapacityOutput1.awk From Ulf.Zibis at gmx.de Fri Dec 24 17:11:08 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 24 Dec 2010 18:11:08 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D13BDF3.7030000@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> Message-ID: <4D14D42C.40700@gmx.de> Am 23.12.2010 22:24, schrieb Ulf Zibis: > You use "ceiling(n/2)". Didn't you mean "ceiling O(N/2)" for consistence? > Sorry, I was confused. But anyway, isn't "(N + 1)/2" more correct ? -Ulf From Ulf.Zibis at gmx.de Sat Dec 25 01:14:33 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 25 Dec 2010 02:14:33 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> Message-ID: <4D154579.9040804@gmx.de> Am 23.12.2010 23:59, schrieb Paul Benedict: > Ulf, a previous email by Remi said only to invoke size() if the collection is a Set. Thanks I missed that. My guess was, that size() should be always faster than instantiating an iterator for the final for-loop, and then seeing, that there is no element. But: Given Set c1 with 100 elements and Set c2 with 0 elements. Then we iterate and compare over 100 elements for nothing. Result map for method disjoint(): c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 |true |true|true |true |true|true Set | 3 |true |t/f |t/f |true|t/f |t/f | 50 |true |t/f |t/f |true|t/f |t/f --------------------------------------------------------------------- | 0 |true |true|true |true |true|true mere | 3 |true |t/f |t/f |true|t/f |t/f | 50 |true |t/f |t/f |true|t/f |t/f --------------------------------------------------------------------- (1) Iteration over in current webrev.3: c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 | c2 |c2 |c2 | c1 |c1 |c1 Set | 3 | c2 |c2 |c2 |c1 |c1 |c1 | 50 | c2 |c2 |c2 |c1 |c1 |c1 --------------------------------------------------------------------- | 0 | c2 |c2 |c2 |none |none|none mere | 3 | c2 |c2 |c2 |none| c1|c2 | 50 | c2 |c2 |c2 |none| c1|c1 --------------------------------------------------------------------- (2) Ideal iteration over: c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 |none |none|none|none|none|none Set | 3 |none|c1/2*|c2*|none|c1 |c1 | 50 |none|c1*|c1/2*|none|c1 |c1 --------------------------------------------------------------------- | 0 |none |none|none|none |none|none mere | 3 |none|c2 |c2 |none|c1/2|c2 | 50 |none|c2 |c2 |none| c1|c1/2 --------------------------------------------------------------------- * Optimum could differ depending on types of Sets e.g. HashSet, TreeSet, so further optimization is thinkable. (3) Ideal iteration over, according "Set.size() can be expensive": (I only found ConcurrentSkipListSet, are there others? Anyway, isn't size() anyhow cheaper than superfluously looping contains() ?) c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 |c1/2|c1/2|c1/2|c1 |c1 |c1 Set | 3 |c1/2|c1/2|c1/2|c1 |c1 |c1 | 50 |c1/2|c1/2|c1/2|c1 |c1 |c1 --------------------------------------------------------------------- | 0 |c2 |c2 |c2 |none |none|none mere | 3 | c2 |c2 |c2 |none|c1/2|c2 | 50 |c2 |c2 |c2|none| c1|c1/2 --------------------------------------------------------------------- Why you introduce variables iterate and contains? You could simply swap c1 with c2... Shortest code for (2) with minimal swapping: int c1size, c2size; if ((c1size= c1.size())== 0 || (c2size= c2.size())== 0) { // At least one collection is empty. Nothing will match. return true; } if (!(c2 instanceof Set)) Optimize:{ // AsSet'scontains() impl predictably performs better(< O(N/2)) // thanmere Collection's, iterate over latter c2, except ... if (!(c1 instanceof Set)) { // If both are mere collections, iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires (N+1)/2comparisons thenchecking // for all c1 elements in c2 would require 76.5 comparisons // vs. all c2 elements in c1 would require 100. if (c1size <= c2size) { break Optimize; } } Collection temp = c1; c1 = c2; c2 = temp; } Shortest code for (3), on a par with (1) with minimal swapping: if (!(c2 instanceof Set)) Optimize:{ // AsSet'scontains() impl predictably performs better(< O(N/2)) // thanmere Collection's, iterate over latter c2, except ... if (!(c1 instanceof Set)) { // Both are mere collections. int c1size, c2size; if ((c1size= c1.size())== 0 || (c2size= c2.size())== 0) { // At least one collection is empty. Nothing will match. return true; } // Iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires (N+1)/2comparisons thenchecking // for all c1 elements in c2 would require 76.5 comparisons // vs. all c2 elements in c1 would require 100. if (c1size <= c2size) { break Optimize; } } Collection temp = c1; c1 = c2; c2 = temp; } -Ulf From Ulf.Zibis at gmx.de Sat Dec 25 01:32:56 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 25 Dec 2010 02:32:56 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> Message-ID: <4D1549C8.9000102@gmx.de> Trying to correct white space ... Am 23.12.2010 23:59, schrieb Paul Benedict: > Ulf, a previous email by Remi said only to invoke size() if the collection is a Set. Thanks I missed that. My guess was, that size() should be always faster than instantiating an iterator for the final for-loop, and then seeing, that there is no element. But: Given Set c1 with 100 elements and Set c2 with 0 elements. Then we iterate and compare over 100 elements for nothing. Result map for method disjoint(): c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 | true | true | true | true | true | true Set | 3 | true | t/f | t/f | true | t/f | t/f | 50 | true | t/f | t/f | true | t/f | t/f --------------------------------------------------------------------- | 0 | true | true | true | true | true | true mere | 3 | true | t/f | t/f | true | t/f | t/f | 50 | true | t/f | t/f | true | t/f | t/f --------------------------------------------------------------------- (1) Iteration over in current webrev.3: c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 | c2 | c2 | c2 | c1 | c1 | c1 Set | 3 | c2 | c2 | c2 | c1 | c1 | c1 | 50 | c2 | c2 | c2 | c1 | c1 | c1 --------------------------------------------------------------------- | 0 | c2 | c2 | c2 | none | none | none mere | 3 | c2 | c2 | c2 | none | c1 | c2 | 50 | c2 | c2 | c2 | none | c1 | c1 --------------------------------------------------------------------- (2) Ideal iteration over: c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 | none | none | none | none | none | none Set | 3 | none | c1/2*| c2* | none | c1 | c1 | 50 | none | c1* | c1/2*| none | c1 | c1 --------------------------------------------------------------------- | 0 | none | none | none | none | none | none mere | 3 | none | c2 | c2 | none | c1/2 | c2 | 50 | none | c2 | c2 | none | c1 | c1/2 --------------------------------------------------------------------- * Optimum could differ depending on types of Sets e.g. HashSet, TreeSet, so further optimization is thinkable. (3) Ideal iteration over, according "Set.size() can be expensive": (I only found ConcurrentSkipListSet, are there others? Anyway, isn't size() anyhow cheaper than superfluously looping contains() ?) c1 | Set | mere c2 | elements | 0 | 3 | 50 | 0 | 3 | 50 --------------------------------------------------------------------- | 0 | c1/2 | c1/2 | c1/2 | c1 | c1 | c1 Set | 3 | c1/2 | c1/2 | c1/2 | c1 | c1 | c1 | 50 | c1/2 | c1/2 | c1/2 | c1 | c1 | c1 --------------------------------------------------------------------- | 0 | c2 | c2 | c2 | none | none | none mere | 3 | c2 | c2 | c2 | none | c1/2 | c2 | 50 | c2 | c2 | c2 | none | c1 | c1/2 --------------------------------------------------------------------- Why you introduce variables iterate and contains? You could simply swap c1 with c2... Shortest code for (2) with minimal swapping: int c1size, c2size; if ((c1size= c1.size())== 0 || (c2size= c2.size())== 0) { // At least one collection is empty. Nothing will match. return true; } if (!(c2 instanceof Set)) Optimize:{ // As Set's contains() impl predictably performs better (< O(N/2)) // than mere Collection's, iterate over latter c2, except ... if (!(c1 instanceof Set)) { // If both are mere collections, iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires (N+1)/2comparisons thenchecking // for all c1 elements in c2 would require 76.5 comparisons // vs. all c2 elements in c1 would require 100. if (c1size <= c2size) { break Optimize; } } Collection temp = c1; c1 = c2; c2 = temp; } Shortest code for (3), on a par with (1) with minimal swapping: if (!(c2 instanceof Set)) Optimize:{ // As Set's contains() impl predictably performs better(< O(N/2)) // than mere Collection's, iterate over latter c2, except ... if (!(c1 instanceof Set)) { // Both are mere collections. int c1size, c2size; if ((c1size= c1.size())== 0 || (c2size= c2.size())== 0) { // At least one collection is empty. Nothing will match. return true; } // Iterate over smaller collection. // E.g. if c1 contains 3 elements and c2 contains 50 elements and // assuming contains() requires (N+1)/2comparisons thenchecking // for all c1 elements in c2 would require 76.5 comparisons // vs. all c2 elements in c1 would require 100. if (c1size <= c2size) { break Optimize; } } Collection temp = c1; c1 = c2; c2 = temp; } -Ulf From valerie.peng at oracle.com Tue Dec 28 01:57:08 2010 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Tue, 28 Dec 2010 01:57:08 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20101228015748.E3BF7477C5@hg.openjdk.java.net> Changeset: adff75ebdc00 Author: valeriep Date: 2010-12-22 19:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/adff75ebdc00 6924489: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_NOT_INITIALIZED Summary: Reset cipher state to un-initialized wherever necessary. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 3254c3ae63fe Author: valeriep Date: 2010-12-27 11:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3254c3ae63fe Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java