February 2009 - core-libs-dev

Fix for 5015163, and my first webrev
by Rémi Forax 15 Oct '09

15 Oct '09

Hi all, bug 5015163 is a RFE that advocate to add a method join (like in Python) to String/StringBuilder/StringBuffer. Here is the corresponding webrev (using the new infrastucture :) http://cr.openjdk.java.net/~forax/5015163/webrev.00/ The patch is against tl repository. Who want to review it ? For the record, i have previously proposed this fix using the jdk-collaboration forum more than one year ago but because i am lazy i haven't take the time to post it here. cheers, Rémi Forax

6 12

Re: [PATCH] 4837946: Implement Karatsuba multiplication algorithm in BigInteger
by Alan Eliasen 06 Jun '09

06 Jun '09

Anonymous member wrote: > Out of curiousity, how does the Java implementation compare to GMP in > terms of speed? (Note: These numbers apply to the *revised* patch that I'll be posting in a few minutes.) It depends on the size of the numbers. When I run the regression tests that I wrote, my updated Java version runs in about 2 minutes. When I run the same regression test in Kaffe using GMP, it takes about 2 *hours*. (Some of the same tests using Java 1.6 take many, many hours without my optimizations for the pow() function). But those are a lot of small numbers. There is a lot of overhead in converting from Java to C types and back, and in Kaffe's relative slowness. And currently, only multiply() has been improved in my Java patches that I've submitted. Kaffe is about 25 times slower on the average program anyway. When you run Kaffe/GMP for very large numbers, Kaffe/GMP starts being very much faster. OpenJDK still can't compete for numbers that are on the cutting edge of number theory. But we'll be much better than we were before. If I were to write the same code in pure C using GMP, then GMP would be much faster. But I haven't done that. So it's hard to compare GMP to Java exactly. But some numbers. For multiplying the numbers 3^1000000 * 3^1000001, (with my fixes to do the exponentiation hundreds of thousands of times faster factored out; without these, JDK 1.6 would be thousands of times slower,) the times for 20 iterations are: JDK 1.6 OpenJDK1.7 with my patches Kaffe w/GMP 292987 ms 28650 ms 866 ms Thus, for numbers of this size, my algorithms are more than 10 times faster than JDK 1.6, but 33 times slower than Kaffe/GMP. For multiplying the somewhat special form 2^1000000 * 2^1000001, (the arguments of this in binary are a 1 followed by a million zeroes) JDK 1.6 OpenJDK1.7 with my patches Kaffe w/GMP 117298 ms 386 ms 474 ms So, my algorithm is 303 times faster than JDK, and just slightly faster than Kaffe/GMP. For multiplying numbers 3^14000000 * 3^14000001, the time for 1 iteration is: JDK 1.6 OpenJDK1.7 with my patches Kaffe w/GMP 3499115 ms 89505 ms 910 ms Thus, for numbers of this size, my patches make it 38.9 times faster, but still 99 times slower than GMP. Sigh. Well, to be expected. If you work with large numbers, GMP becomes ridiculously faster. Kaffe with GMP becomes only slightly slower than pure GMP as the portion of time in Java gets small. GMP includes 3-way Toom-Cook multiplication, and the much faster FFT multiplication (which is O(n)) for very large numbers, and hand-crafted assembly language that uses 64-bit instructions and limbs on my 64-bit architecture (as opposed to the 32-bit ints used in BigInteger. Hopefully some day in the future, BigInteger will be rewritten to use longs internally instead of ints. Multiplying two 64-bit longs does 4 times as much work as multiplying two 32-bit ints, and will thus likely be significantly faster, especially on 64-bit architectures.) So GMP is still very much faster for very large numbers. It is also *much* faster in turning numbers into strings, and in exponentiation. The algorithms in BigInteger are horrible for pow() and toString(). See the following bugs: 4641897: BigInteger.toString() algorithm slow for large numbers http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 4646474: BigInteger.pow() algorithm slow in 1.4.0 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 I have several fixes for both of these. My JVM-based programming language Frink ( http://futureboy.us/frinkdocs/ ) implements many of these improvements, and is much faster for a variety of arguments. I just need to finish improving these for a variety of different arguments, and considering the threading and memory-size-vs-speed tradeoffs in implementing toString efficiently. -- Alan Eliasen | "Furious activity is no substitute eliasen(a)mindspring.com | for understanding." http://futureboy.us/ | --H.H. Williams

4 8

New charset IBM1153
by Boris.Just＠wuestenrot.at 04 Apr '09

04 Apr '09

Hi everybody! Is there any possibility that a further charset (HOST IBM CP1153/1375 Latin 2 - EBCDIC Multilingual) will be part of a next JRE version or update? It is quite a new charset and is simular to IBM870, but has the EURO sign in addition. As more and more countries in eastern europe change their currency to euro or use it for payment, it is getting more and more important (in particular for mainframes). We have a problem just now with a DB2 java driver, which does not support this charset because it is at the moment not part of the standard JVM. Thanks for your reply in advance! Best regards Boris Just

3 5

covariant returns for CharBuffer.subSequence
by Martin Buchholz 01 Apr '09

01 Apr '09

We would like to have return types of methods be the most covariant as is reasonable. The only problem is compatibility. For classes that cannot be subclassed by users, changing covariant returns is almost 100% compatible. (We all know that no change is 100.000000% compatible) The spec for CharBuffer.CharSequence appears to guarantee that the returned object is itself a CharBuffer, so all we need to change is the return type: Hence: diff --git a/src/share/classes/java/nio/ByteBufferAs-X-Buffer.java b/src/share/classes/java/nio/ByteBufferAs-X-Buffer.java --- a/src/share/classes/java/nio/ByteBufferAs-X-Buffer.java +++ b/src/share/classes/java/nio/ByteBufferAs-X-Buffer.java @@ -186,7 +186,7 @@ // --- Methods to support CharSequence --- - public CharSequence subSequence(int start, int end) { + public CharBuffer subSequence(int start, int end) { int pos = position(); int lim = limit(); assert (pos <= lim); diff --git a/src/share/classes/java/nio/Direct-X-Buffer.java b/src/share/classes/java/nio/Direct-X-Buffer.java --- a/src/share/classes/java/nio/Direct-X-Buffer.java +++ b/src/share/classes/java/nio/Direct-X-Buffer.java @@ -391,7 +391,7 @@ // --- Methods to support CharSequence --- - public CharSequence subSequence(int start, int end) { + public CharBuffer subSequence(int start, int end) { int pos = position(); int lim = limit(); assert (pos <= lim); diff --git a/src/share/classes/java/nio/Heap-X-Buffer.java b/src/share/classes/java/nio/Heap-X-Buffer.java --- a/src/share/classes/java/nio/Heap-X-Buffer.java +++ b/src/share/classes/java/nio/Heap-X-Buffer.java @@ -566,7 +566,7 @@ // --- Methods to support CharSequence --- - public CharSequence subSequence(int start, int end) { + public CharBuffer subSequence(int start, int end) { if ((start < 0) || (end > length()) || (start > end)) diff --git a/src/share/classes/java/nio/StringCharBuffer.java b/src/share/classes/java/nio/StringCharBuffer.java --- a/src/share/classes/java/nio/StringCharBuffer.java +++ b/src/share/classes/java/nio/StringCharBuffer.java @@ -99,7 +99,7 @@ return str.toString().substring(start + offset, end + offset); } - public final CharSequence subSequence(int start, int end) { + public final CharBuffer subSequence(int start, int end) { try { int pos = position(); return new StringCharBuffer(str, -1, diff --git a/src/share/classes/java/nio/X-Buffer.java b/src/share/classes/java/nio/X-Buffer.java --- a/src/share/classes/java/nio/X-Buffer.java +++ b/src/share/classes/java/nio/X-Buffer.java @@ -1245,7 +1245,7 @@ * If the preconditions on <tt>start</tt> and <tt>end</tt> * do not hold */ - public abstract CharSequence subSequence(int start, int end); + public abstract CharBuffer subSequence(int start, int end); // --- Methods to support Appendable ---

6 13

hg: jdk7/tl/langtools: 6786690: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - DL tag and nesting issue
by bhavesh.patel＠sun.com 28 Feb '09

28 Feb '09

Changeset: 5240b1120530 Author: bpatel Date: 2009-02-27 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5240b1120530 6786690: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - DL tag and nesting issue Reviewed-by: jjg ! 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/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/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.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/PackageTreeWriter.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/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.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 ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java + test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C2.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C3.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C4.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C5.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.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/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java

1 0

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
by David M. Lloyd 28 Feb '09

28 Feb '09

On 02/27/2009 12:52 PM, Bob Lee wrote: > On Fri, Feb 27, 2009 at 10:40 AM, David M. Lloyd <david.lloyd(a)redhat.com> wrote: >> Seems like a reasonable alternate approach, *however* I think there ought to >> be a way to clear the reference as well, which would complicate matters a >> little with respect to the internal data structure. > > Do you have a use case? > > *If* we wanted to support removals, I would do something like this: > > public class ClassLoader { > public Reference<?> keepReferenceTo(Object o) { ... } > ... > } > > You could call clear() on the returned reference to clear the > ClassLoader's reference. Internally, it would use some sort of CAS > doubly-linked list. A couple use cases, off the top of my head: 1) I've got a set of FooBars that associate with Classes; now for whatever reason, I want to change the FooBar that is associated with the Class. The old FooBar is now completely unreferenced; keeping a reference to it is a leak. 2) I've got an application server deployment that provides some kind of service by class, so I stash refs on the ClassLoaders of the Classes for whom the service is provided. I want to undeploy my application, but all those classloaders have strong refs to my deployment. They all have to be cleared or you face a OOM: PermGen after a few redeployments. In this case I'd use a stop() + finalize() on my service which clears them. 2a) OK, you say, just stash an Object or something that isn't from my deployment's classloader. Nevertheless, every time you redeploy, you're now permanently leaking data and you *will* run out of heap space eventually, even if your deployment is meticulous about cleaning up references. My solution solves the problem by having a "key" (similar to your Reference<?> above) - however the difference is that you use one key instead of many References (for a space savings), so it works like this: - App keeps strong reference to key - Class(loader) keeps a weak->strong map of keys to refs - When app is removed, the key goes away, and all the references simply clean themselves up (in other words, no special action is needed on the part of the app to clean up refs stashed on other class(loader)s) Using a CAS linked list like you describe would be very nice, from a performance perspective, but you lose a little of the manageability that you would gain from not having to worry about manually cleaning up all your junk. - DML

3 10

hg: jdk7/tl/jdk: 6809504: Remove enctype="text/xml" from the offline registration page
by mandy.chung＠sun.com 28 Feb '09

28 Feb '09

Changeset: 0da45c759116 Author: mchung Date: 2009-02-27 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0da45c759116 6809504: Remove enctype="text/xml" from the offline registration page Summary: Remove enctype="text/xml" from register.html and other localized versions Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html

1 0

hg: jdk7/tl/jdk: 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily
by mandy.chung＠sun.com 27 Feb '09

27 Feb '09

Changeset: de1d02ad2d1d Author: mchung Date: 2009-02-27 13:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de1d02ad2d1d 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Summary: Lazily initialize the hexFloatPattern static field Reviewed-by: darcy ! src/share/classes/sun/misc/FloatingDecimal.java

1 0

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
by Bob Lee 27 Feb '09

27 Feb '09

I have a simpler and more secure solution. I just need one method on ClassLoader: public class ClassLoader { public void keepReferenceTo(Object o) { ... } ... } The ClassLoader would keep a strong reference to the passed reference indefinitely (using some sort of minimal memory footprint, wait-free data structure internally). We could add a convenience method to Class, too, but it would just delegate to the same method on the Class's loader. Now, my library code can just keep a weak reference to the object, and I know it won't be cleared until the class loader is reclaimed. Bob

2 2

Re: Should Lance be a member of the core libraries group?
by Iris Clark 27 Feb '09

27 Feb '09

Hi, Alan. Before I consider initiating the CFV, I have one question. Is JDBC really considered part of "Core Libraries"? We want to make sure that "Core Libraries" does not become the catch-all for APIs that don't belong anywhere else. As far as I know Lance already has all the privileges necessary to enhance JDBC, including commit rights. What additional benefits would becoming a member of Core Libraries confer on him? Thanks, iris http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001141.h…

3 2