From Thomas.Hawtin at Sun.COM  Mon Feb  1 00:48:34 2010
From: Thomas.Hawtin at Sun.COM (Tom Hawtin)
Date: Mon, 01 Feb 2010 00:48:34 +0000
Subject: Serialization problem
In-Reply-To: <4B64D25E.5030709@joda.org>
References: <4B64D25E.5030709@joda.org>
Message-ID: <4B6624E2.6020307@sun.com>

Stephen Colebourne wrote:

> Workarounds include lazily creating the caches in transient fields, 
> bloating the serialzed data, using reflection or creating a dummy inner 
> class to act as the serialized form. All are rubbish solutions.

IMO, a "serial proxy" is a good rubbish solution. Nested classes aren't 
great for serialisation - I suggest a "package private" outer class.

A big issue here is that readObject is not a real constructor. It should 
be. Although even that wouldn't solve all the problems that serial 
proxies can verbosely (or instance, determining actual implementation 
class).

Tom


From david.lloyd at redhat.com  Mon Feb  1 16:10:00 2010
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 01 Feb 2010 10:10:00 -0600
Subject: Serialization problem
In-Reply-To: <4b4f45e01001311250r3f83cdal8b314aafb5d7b735@mail.gmail.com>
References: <4B64D25E.5030709@joda.org> <4B65873E.1070006@sun.com>
	<4b4f45e01001311250r3f83cdal8b314aafb5d7b735@mail.gmail.com>
Message-ID: <4B66FCD8.2010609@redhat.com>

There is no need to deal with Unsafe for this.  If you use a reflection 
Field, while ugly, it *does* publish writes to a final field with volatile 
semantics internally.  I would argue that using a ThreadLocal in this 
fashion would be far uglier.

There is another alternative.  Use writeReplace to write a minimal 
representation class, then use readResolve on that representation object to 
transform it back again using standard constructors.

- DML

On 01/31/2010 02:50 PM, Stephen Colebourne wrote:
> Thanks for the info. Unfortunately, JSR-310 cannot use unsafe, as it
> needs to be usable outside the JDK.
>
> For info, I compared the sizes of a neatly trimmed output (using a
> Serialization proxy class) with the best achievable without one. 277
> bytes without, 99 bytes with a proxy. So, this isn't an esoteric
> problem.
>
> What would you think of using a ThreadLocal to cache the result value
> between readObject() and readResolve() ? (making everything transient
> and using a dedicated format)
>
> What do you think of the general idea of readObjectAndResolve() ? (for JDK 7+)
>
> Stephen
>
>
> On 31 January 2010 13:35, Alan Bateman<Alan.Bateman at sun.com>  wrote:
>> Stephen Colebourne wrote:
>>>
>>> I thought I'd raise an issue with serialization that I've had a problem
>>> with more than once. Perhaps there is an obvious easy solution, but I can't
>>> see it (I can see hard workarounds...)
>>>
>>> In JSR-310 we have lots of immutable classes. One of these stores four
>>> fields:
>>>
>>>   private final String name
>>>   private final Duration duration
>>>   private final List<PeriodField>  periods
>>>   private final int hashCode
>>>
>>> For serialization, I only need to store the name, duration and element
>>> zero from the periods list. (The rest of the period list is a cache derived
>>> from the first element. Similarly, I want to cache the hash code in the
>>> constructor as this could be performance critical.). Storing just these
>>> fields can be done easily using writeObject()
>>
>> In the JDK there are places that use unsafe's putObjectVolatile to
>> workaround this. It's also possible to use reflection hacks in some cases.
>> There is more discussion here:
>>   http://bugs.sun.com/view_bug.do?bug_id=6379948
>>
>> Doug Lea and the concurrency group were working on a Fences API that
>> included a method for safe publication so that one can get the same effects
>> as final for cases where it's not possible to declare a field as field.
>>
>> For the hashCode case above then perhaps it doesn't necessary to compute the
>> hash code in the constructor or when reconstituting the object. Instead
>> perhaps the hashCode method could compute and set the hashCode field when it
>> sees the value is 0 (no need to be volatile and shouldn't matter if more
>> than one thread computes it).
>>
>> -Alan.
>>
>>
>>


From jonathan.gibbons at sun.com  Tue Feb  2 01:06:50 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 02 Feb 2010 01:06:50 +0000
Subject: hg: jdk7/tl/langtools: 6919986: [308] change size of type_index (of
	CLASS_EXTENDS and THROWS) from byte to short
Message-ID: <20100202010653.333D441A1A@hg.openjdk.java.net>

Changeset: 732510cc3538
Author:    jjg
Date:      2010-02-01 17:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/732510cc3538

6919986: [308] change size of type_index (of CLASS_EXTENDS and THROWS) from byte to short
Reviewed-by: darcy, jjg
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java



From ahughes at redhat.com  Tue Feb  2 10:55:58 2010
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Tue, 02 Feb 2010 10:55:58 +0000
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings from sun.io converters
	and allow compiling with JAVAC_MAX_WARNINGS=true
Message-ID: <20100202105654.49BC641ABA@hg.openjdk.java.net>

Changeset: 7dadd2951a8b
Author:    andrew
Date:      2010-02-02 10:55 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7dadd2951a8b

6921740: Eliminate warnings from sun.io converters and allow compiling with JAVAC_MAX_WARNINGS=true
Summary: Fix sun.io converters unchecked and cast warnings produced by -Xlint:all
Reviewed-by: alanb, sherman

! make/java/sun_nio/Makefile
! src/share/classes/sun/io/ByteToCharUTF8.java
! src/share/classes/sun/io/CharToByteUnicode.java
! src/share/classes/sun/io/CharacterEncoding.java
! src/share/classes/sun/io/Converters.java
! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java



From Ulf.Zibis at gmx.de  Tue Feb  2 13:09:35 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 02 Feb 2010 14:09:35 +0100
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings from sun.io
	converters and allow compiling with JAVAC_MAX_WARNINGS=true
In-Reply-To: <20100202105654.49BC641ABA@hg.openjdk.java.net>
References: <20100202105654.49BC641ABA@hg.openjdk.java.net>
Message-ID: <4B68240F.3080904@gmx.de>

Hi,

in most cases you use the empty diamond operator '<>' on instantiation, 
but not for SoftReference: "new SoftReference<Charset>(cs)" in 
AbstractCharsetProvider.java
Why?

I don't see a big advantage for casting to (Class<?>) against (Class) 
for the cache of Converters.java. Wouldn't you better use a small helper 
class:
class CacheEntry {
     String encoding;
     Class<?> converter;
}

Maybe you would like my more general approach, which eliminates the need 
of any XxxxToYyyyZzzz converters:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone3/src/sun/io/Converters.java?rev=530&view=markup
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/tags/milestone3/src/sun/io/?rev=530


in AbstractCharsetProvider.java you could simply code:
Charset cs = (Charset)Class.forName(packagePrefix+'.'+cln, true,
         this.getClass().getClassLoader()).newInstance();


-Ulf


Am 02.02.2010 11:55, schrieb ahughes at redhat.com:
> Changeset: 7dadd2951a8b
> Author:    andrew
> Date:      2010-02-02 10:55 +0000
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7dadd2951a8b
>
> 6921740: Eliminate warnings from sun.io converters and allow compiling with JAVAC_MAX_WARNINGS=true
> Summary: Fix sun.io converters unchecked and cast warnings produced by -Xlint:all
> Reviewed-by: alanb, sherman
>
> ! make/java/sun_nio/Makefile
> ! src/share/classes/sun/io/ByteToCharUTF8.java
> ! src/share/classes/sun/io/CharToByteUnicode.java
> ! src/share/classes/sun/io/CharacterEncoding.java
> ! src/share/classes/sun/io/Converters.java
> ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java
>
>
>    



From forax at univ-mlv.fr  Tue Feb  2 13:30:41 2010
From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=)
Date: Tue, 02 Feb 2010 14:30:41 +0100
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings from
	sun.io	converters and allow compiling with JAVAC_MAX_WARNINGS=true
In-Reply-To: <4B68240F.3080904@gmx.de>
References: <20100202105654.49BC641ABA@hg.openjdk.java.net>
	<4B68240F.3080904@gmx.de>
Message-ID: <4B682901.90302@univ-mlv.fr>

Le 02/02/2010 14:09, Ulf Zibis a ?crit :
> Hi,
>
> in most cases you use the empty diamond operator '<>' on 
> instantiation, but not for SoftReference: "new 
> SoftReference<Charset>(cs)" in AbstractCharsetProvider.java
> Why?

SoftReference constructor is SoftReference(T), so there is two ways to 
infer the type argument.

With this code:
SoftReference<Charset> ref = new SoftReference<>(cs);
the type argument can be infered from the lhs of the assignation or
by the declared type of the parameter (here cs).

Knowing that the algorithm for infering the type argument changed and 
will change
(even if its in a backward compatible way), it seems to be a good rational
to only use diamond when the type can be only infered from the lhs type.
At least until, the JLS specifies the algorithm.

>
> I don't see a big advantage for casting to (Class<?>) against (Class) 
> for the cache of Converters.java.

Rules for Class<?> and Class are not the same.
Class should be only used when dealing with legacy code.

[...]
>
> -Ulf

R?mi


From Ulf.Zibis at gmx.de  Tue Feb  2 16:26:14 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 02 Feb 2010 17:26:14 +0100
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings
	from	sun.io	converters
	and allow compiling with JAVAC_MAX_WARNINGS=true
In-Reply-To: <4B682901.90302@univ-mlv.fr>
References: <20100202105654.49BC641ABA@hg.openjdk.java.net>	<4B68240F.3080904@gmx.de>
	<4B682901.90302@univ-mlv.fr>
Message-ID: <4B685226.6020003@gmx.de>

Am 02.02.2010 14:30, schrieb R?mi Forax:
> Le 02/02/2010 14:09, Ulf Zibis a ?crit :
>> Hi,
>>
>> in most cases you use the empty diamond operator '<>' on 
>> instantiation, but not for SoftReference: "new 
>> SoftReference<Charset>(cs)" in AbstractCharsetProvider.java
>> Why?
>
> SoftReference constructor is SoftReference(T), so there is two ways to 
> infer the type argument.
>
> With this code:
> SoftReference<Charset> ref = new SoftReference<>(cs);
> the type argument can be infered from the lhs of the assignation or
> by the declared type of the parameter (here cs).
>

So you agree with me, that new SoftReference<>(cs) would suffice ???


>>
>> I don't see a big advantage for casting to (Class<?>) against (Class) 
>> for the cache of Converters.java.
>
> Rules for Class<?> and Class are not the same.
> Class should be only used when dealing with legacy code.

One of the advantages of generics is the avoidability of casts.
So I wanted to say, if a code becomes reengineerd in generic way, then 
it should be done in "full way".

-Ulf

P.S.: Additionally note: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853699





From forax at univ-mlv.fr  Tue Feb  2 17:47:56 2010
From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=)
Date: Tue, 02 Feb 2010 18:47:56 +0100
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings
	from	sun.io	converters
	and allow compiling with JAVAC_MAX_WARNINGS=true
In-Reply-To: <4B685226.6020003@gmx.de>
References: <20100202105654.49BC641ABA@hg.openjdk.java.net>	<4B68240F.3080904@gmx.de>
	<4B682901.90302@univ-mlv.fr> <4B685226.6020003@gmx.de>
Message-ID: <4B68654C.2050503@univ-mlv.fr>

Le 02/02/2010 17:26, Ulf Zibis a ?crit :
> Am 02.02.2010 14:30, schrieb R?mi Forax:
>> Le 02/02/2010 14:09, Ulf Zibis a ?crit :
>>> Hi,
>>>
>>> in most cases you use the empty diamond operator '<>' on 
>>> instantiation, but not for SoftReference: "new 
>>> SoftReference<Charset>(cs)" in AbstractCharsetProvider.java
>>> Why?
>>
>> SoftReference constructor is SoftReference(T), so there is two ways 
>> to infer the type argument.
>>
>> With this code:
>> SoftReference<Charset> ref = new SoftReference<>(cs);
>> the type argument can be infered from the lhs of the assignation or
>> by the declared type of the parameter (here cs).
>>
>
> So you agree with me, that new SoftReference<>(cs) would suffice ???

No.
The code is:

cache.put(csn, new SoftReference<Charset>(cs));


It will not compile, because Object will be infered.
Diamond doesn't take care about method's parameter types
(Maurizio correct me if I'm wrong)


>
> -Ulf
>

R?mi



From jonathan.gibbons at sun.com  Tue Feb  2 18:56:51 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 02 Feb 2010 18:56:51 +0000
Subject: hg: jdk7/tl/langtools: 6918625: handle annotations on array class
	literals
Message-ID: <20100202185657.D68DA41B3E@hg.openjdk.java.net>

Changeset: b0a68258360a
Author:    jjg
Date:      2010-02-02 10:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b0a68258360a

6918625: handle annotations on array class literals
Reviewed-by: jjg, darcy
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
! src/share/classes/com/sun/tools/javap/AnnotationWriter.java
+ test/tools/javap/typeAnnotations/ArrayClassLiterals2.java



From Joe.Darcy at Sun.COM  Wed Feb  3 02:44:18 2010
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 02 Feb 2010 18:44:18 -0800
Subject: Math project or subproject
In-Reply-To: <4B635DCC.9010207@mindspring.com>
References: <4B62A425.7040506@sun.com> <4B635DCC.9010207@mindspring.com>
Message-ID: <4B68E302.8090608@sun.com>

Alan Eliasen wrote:

[snip]
>
>    I'm the submitter of these patches [BigInteger] which are almost 
> two years old in a couple of weeks, with still no approval.  And these 
> multiplication patches are only a small part of the work that needs to 
> be done on BigInteger.  I also have orders-of-magnitude improvements 
> for pow() and toString(), both of which use extremely slow 
> algorithms.  I was asked to make patches as small as possible so they 
> could be reviewed quickly, so my submitted patches have just been for 
> multiplication.

Sun Microsystems Inc. is in the last throes of the process of ceasing to 
exist as an independent entity.  This was preceded by many years of 
marginal financial performance of the company.  Neither condition 
enhanced the ability of those of us working at Sun to make progress on 
OpenJDK, including making progress on infrastructure to collaborate more 
effectively with developers in the external community.

>
>    Joe Darcy, what is your current status on reviewing these patches? 
> Can you delegate this to Dmitry or Xiaobin if you don't appear to have 
> time to do it?

I'd like to review your patches by the end of March 2010.

[snip]

>
>    I think OpenJDK *contributors* need some evidence that their 
> contributions are being looked at, or they'll stop contributing, 
> and/or move to other platforms with better numerics.  Some of us have 
> spent literally weeks of unpaid work improving performance, getting 
> world-class outside reviewers to look over them and reduce Sun's 
> workload, etc.  It's very depressing to wait over two years for 
> approval of a well-known algorithm that is usually assigned as a 
> homework assignment in undergrad courses.

I again apologize for the increasingly tardy reviews of your work.  If 
it is any consolation, I have my own projects, including fun ones, which 
have been deferred for months and sometimes years.  I'm confident your 
contribution will be a fine addition to the millions and millions of 
lines of code already freely available in OpenJDK.

-Joe


From weijun.wang at sun.com  Wed Feb  3 09:05:38 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Wed, 03 Feb 2010 09:05:38 +0000
Subject: hg: jdk7/tl/jdk: 6922482: keytool's help on -file always shows
	'output file'
Message-ID: <20100203090557.EA89A41C0D@hg.openjdk.java.net>

Changeset: e6ab5fabaf7e
Author:    weijun
Date:      2010-02-03 17:04 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6ab5fabaf7e

6922482: keytool's help on -file always shows 'output file'
Reviewed-by: wetmore

! src/share/classes/sun/security/tools/KeyTool.java
+ test/sun/security/tools/keytool/file-in-help.sh



From jonathan.gibbons at sun.com  Wed Feb  3 19:30:03 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 03 Feb 2010 19:30:03 +0000
Subject: hg: jdk7/tl/langtools: 6922429: extend tree position test waiver
Message-ID: <20100203193007.89B9541CA0@hg.openjdk.java.net>

Changeset: 41ed86f86585
Author:    jjg
Date:      2010-02-03 11:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/41ed86f86585

6922429: extend tree position test waiver
Reviewed-by: darcy

! test/tools/javac/treepostests/TreePosTest.java



From jonathan.gibbons at sun.com  Wed Feb  3 19:34:44 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 03 Feb 2010 19:34:44 +0000
Subject: hg: jdk7/tl/langtools: 6922300: [308] populate the reference_info for
	type annotations targeting primitive class literals
Message-ID: <20100203193447.15D9E41CA3@hg.openjdk.java.net>

Changeset: f65d652cb6af
Author:    jjg
Date:      2010-02-03 11:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f65d652cb6af

6922300: [308] populate the reference_info for type annotations targeting primitive class literals
Reviewed-by: darcy, jjg
Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu

! src/share/classes/com/sun/tools/javac/jvm/Gen.java



From jonathan.gibbons at sun.com  Thu Feb  4 01:00:01 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 04 Feb 2010 01:00:01 +0000
Subject: hg: jdk7/tl/langtools: 6921979: add test program to verify
	annotations are attached to nodes as expected
Message-ID: <20100204010005.8EB9C41CF3@hg.openjdk.java.net>

Changeset: 4c844e609d81
Author:    jjg
Date:      2010-02-03 16:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4c844e609d81

6921979: add test program to verify annotations are attached to nodes as expected
Reviewed-by: darcy

+ test/tools/javac/treeannotests/AnnoTreeTests.java
+ test/tools/javac/treeannotests/DA.java
+ test/tools/javac/treeannotests/TA.java
+ test/tools/javac/treeannotests/Test.java
+ test/tools/javac/treeannotests/TestProcessor.java



From jonathan.gibbons at sun.com  Thu Feb  4 18:16:14 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 04 Feb 2010 18:16:14 +0000
Subject: hg: jdk7/tl/langtools: 6923080: TreeScanner.visitNewClass should scan
	tree.typeargs
Message-ID: <20100204181622.B36DC41DF7@hg.openjdk.java.net>

Changeset: 4b4e282a3146
Author:    jjg
Date:      2010-02-04 10:14 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4b4e282a3146

6923080: TreeScanner.visitNewClass should scan tree.typeargs
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/tree/T6923080.java
+ test/tools/javac/tree/TreeScannerTest.java



From Ulf.Zibis at gmx.de  Fri Feb  5 00:15:02 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 05 Feb 2010 01:15:02 +0100
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings
	from	sun.io	converters
	and allow compiling with JAVAC_MAX_WARNINGS=true
In-Reply-To: <4B68654C.2050503@univ-mlv.fr>
References: <20100202105654.49BC641ABA@hg.openjdk.java.net>	<4B68240F.3080904@gmx.de>
	<4B682901.90302@univ-mlv.fr> <4B685226.6020003@gmx.de>
	<4B68654C.2050503@univ-mlv.fr>
Message-ID: <4B6B6306.8040404@gmx.de>

Am 02.02.2010 18:47, schrieb R?mi Forax:
> Le 02/02/2010 17:26, Ulf Zibis a ?crit :
>> Am 02.02.2010 14:30, schrieb R?mi Forax:
>>> Le 02/02/2010 14:09, Ulf Zibis a ?crit :
>>>> Hi,
>>>>
>>>> in most cases you use the empty diamond operator '<>' on 
>>>> instantiation, but not for SoftReference: "new 
>>>> SoftReference<Charset>(cs)" in AbstractCharsetProvider.java
>>>> Why?
>>>
>>> SoftReference constructor is SoftReference(T), so there is two ways 
>>> to infer the type argument.
>>>
>>> With this code:
>>> SoftReference<Charset> ref = new SoftReference<>(cs);
>>> the type argument can be infered from the lhs of the assignation or
>>> by the declared type of the parameter (here cs).
>>>
>>
>> So you agree with me, that new SoftReference<>(cs) would suffice ???
>
> No.
> The code is:
>
> cache.put(csn, new SoftReference<Charset>(cs));
>
>
> It will not compile, because Object will be infered.
> Diamond doesn't take care about method's parameter types

Hm?
1. Why ? (IMO would be resonable)
2. Didn't you say, type argument can be infered by the declared type of 
the parameter (here cs) ?

-Ulf




From kelly.ohair at sun.com  Fri Feb  5 02:36:24 2010
From: kelly.ohair at sun.com (kelly.ohair at sun.com)
Date: Fri, 05 Feb 2010 02:36:24 +0000
Subject: hg: jdk7/tl/jaxp: 6923146: Upgrade to JAXP 1.4.3
Message-ID: <20100205023624.C05DF41E6F@hg.openjdk.java.net>

Changeset: df2e196a5f01
Author:    ohair
Date:      2010-02-03 16:44 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/df2e196a5f01

6923146: Upgrade to JAXP 1.4.3
Reviewed-by: darcy

! jaxp.properties



From xueming.shen at sun.com  Fri Feb  5 08:13:48 2010
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Fri, 05 Feb 2010 08:13:48 +0000
Subject: hg: jdk7/tl/jdk: 6919132: Regex \P{Lu} selects half of a surrogate
	pari
Message-ID: <20100205081442.6ED3E41EC1@hg.openjdk.java.net>

Changeset: a39e899aa5dc
Author:    sherman
Date:      2010-02-05 00:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a39e899aa5dc

6919132: Regex \P{Lu} selects half of a surrogate pari
Summary: To use StartS for complement category/block class
Reviewed-by: martin, okutsu

! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java



From forax at univ-mlv.fr  Fri Feb  5 10:20:47 2010
From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=)
Date: Fri, 05 Feb 2010 11:20:47 +0100
Subject: hg: jdk7/tl/jdk: 6921740: Eliminate warnings
	from	sun.io	converters
	and allow compiling with JAVAC_MAX_WARNINGS=true
In-Reply-To: <4B6B6306.8040404@gmx.de>
References: <20100202105654.49BC641ABA@hg.openjdk.java.net>	<4B68240F.3080904@gmx.de>
	<4B682901.90302@univ-mlv.fr> <4B685226.6020003@gmx.de>
	<4B68654C.2050503@univ-mlv.fr> <4B6B6306.8040404@gmx.de>
Message-ID: <4B6BF0FF.7000009@univ-mlv.fr>

Le 05/02/2010 01:15, Ulf Zibis a ?crit :
> Am 02.02.2010 18:47, schrieb R?mi Forax:
>> Le 02/02/2010 17:26, Ulf Zibis a ?crit :
>>> Am 02.02.2010 14:30, schrieb R?mi Forax:
>>>> Le 02/02/2010 14:09, Ulf Zibis a ?crit :
>>>>> Hi,
>>>>>
>>>>> in most cases you use the empty diamond operator '<>' on 
>>>>> instantiation, but not for SoftReference: "new 
>>>>> SoftReference<Charset>(cs)" in AbstractCharsetProvider.java
>>>>> Why?
>>>>
>>>> SoftReference constructor is SoftReference(T), so there is two ways 
>>>> to infer the type argument.
>>>>
>>>> With this code:
>>>> SoftReference<Charset> ref = new SoftReference<>(cs);
>>>> the type argument can be infered from the lhs of the assignation or
>>>> by the declared type of the parameter (here cs).
>>>>
>>>
>>> So you agree with me, that new SoftReference<>(cs) would suffice ???
>>
>> No.
>> The code is:
>>
>> cache.put(csn, new SoftReference<Charset>(cs));
>>
>>
>> It will not compile, because Object will be infered.
>> Diamond doesn't take care about method's parameter types
>
> Hm?
> 1. Why ? (IMO would be resonable)
> 2. Didn't you say, type argument can be infered by the declared type 
> of the parameter (here cs) ?
>
> -Ulf
>

For the whole story see:
http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/002393.html

R?mi





From kevinb at google.com  Fri Feb  5 18:50:00 2010
From: kevinb at google.com (Kevin Bourrillion)
Date: Fri, 5 Feb 2010 10:50:00 -0800
Subject: Math project or subproject
In-Reply-To: <64efa1ba1001310902s6324599fqcd5a38e510bff696@mail.gmail.com>
References: <4B62A425.7040506@sun.com>
	<64efa1ba1001310902s6324599fqcd5a38e510bff696@mail.gmail.com>
Message-ID: <108fcdeb1002051050l1f9bd306i3f120f97640a6056@mail.gmail.com>

On Sun, Jan 31, 2010 at 9:02 AM, Patrick Wright <pdoubleya at gmail.com> wrote:

In addition, I think that having an open-source micro-benchmarking
> library for this purpose would be very helpful. It might not be
> perfect or all-encompassing, but it would allow researchers and
> tinkerers a base on which to test their own code, and on which to base
> arguments of "improvements" to the current libs. In essence, it would
> be like saying that the OpenJDK is written as it is because it works
> well in these standard benchmarks, and if someone thinks they have
> improvements, they have to prove it against the same benchmarks that
> Sun/Oracle has used for their own decision-making.
>
> There is/was a Sun project I mentioned on another JDK thread, Japex
> (search online) which is a test harness for micro-benchmarking.
> Perhaps something like this could provide a standard benchmarking,
> with records of historical results, into which different tests could
> be plugged. I don't have any reason to prefer Japex over Caliper or
> another framework; in general I think that a framework that could take
> care (at least) of isolating the warm-up phase, taking and recording
> measurements, etc. would be better than people starting from scratch
> in main() each time they write a benchmark.
>

FWIW, this is a very accurate depiction of our goals for Caliper and the
reasons why we're making it.  Development has been proceeding in fits and
starts (presently: it's throwing a "fit"), but we intend to keep at it until
it has become a very useful tool for you and others who do this kind of
work.

If you'd like to keep tabs on our development -- possibly even help? (dare I
dream?) -- please drop me a line and I'll add you to our mailing list!


-- 
Kevin Bourrillion @ Google
internal:  http://go/javalibraries
external: guava-libraries.googlecode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100205/050ae344/attachment.html>

From bradford.wetmore at sun.com  Sat Feb  6 01:07:13 2010
From: bradford.wetmore at sun.com (bradford.wetmore at sun.com)
Date: Sat, 06 Feb 2010 01:07:13 +0000
Subject: hg: jdk7/tl/jdk: 6923976: TestProviderLeak.java is using too small of
	an initial heap under newer Hotspot (b79+)
Message-ID: <20100206010751.E300441FBF@hg.openjdk.java.net>

Changeset: 7136683a33d2
Author:    wetmore
Date:      2010-02-05 17:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7136683a33d2

6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+)
Reviewed-by: ohair

! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java



From xueming.shen at sun.com  Sat Feb  6 17:31:17 2010
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Sat, 06 Feb 2010 17:31:17 +0000
Subject: hg: jdk7/tl/jdk: 6923692: java/classes_util TEST_BUG:ReadZip.java
	fails when
Message-ID: <20100206173207.B11DE4144C@hg.openjdk.java.net>

Changeset: 445b9928fb70
Author:    sherman
Date:      2010-02-06 09:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/445b9928fb70

6923692: java/classes_util TEST_BUG:ReadZip.java fails when
Summary: to create the test file at test.dir
Reviewed-by: alanb

! test/java/util/zip/ZipFile/ReadZip.java



From Mandy.Chung at Sun.COM  Tue Feb  9 01:40:38 2010
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Mon, 08 Feb 2010 17:40:38 -0800
Subject: Review request for 6924497:
	HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
Message-ID: <4B70BD16.10908@sun.com>

Dan,

Can you review the fix for:
  6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE

Webrev at:
  http://cr.openjdk.java.net/~mchung/6924497/webrev.00/

The VM fix for 6898160 updates the jmm_GetVMGlobals function 
to filter out unsupported type and the returning array may contain 
null elements.  The sun.management.Flag class needs to check 
for null elements and handle unsupported types gracefully.

Thanks
Mandy



From Daniel.Daugherty at Sun.COM  Tue Feb  9 05:13:48 2010
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Mon, 08 Feb 2010 22:13:48 -0700
Subject: Review request for 6924497:
	HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
In-Reply-To: <4B70BD16.10908@sun.com>
References: <4B70BD16.10908@sun.com>
Message-ID: <4B70EF0C.8000705@sun.com>

Mandy Chung wrote:
> Dan,
>
> Can you review the fix for:
>  6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
>
> Webrev at:
>  http://cr.openjdk.java.net/~mchung/6924497/webrev.00/
src/share/classes/sun/management/Flag.java
    line 95 - I don't local var 'c' is needed here or on line 99.

src/share/native/sun/management/Flag.c
    No comments.

I'll be on the look  out for the VM fix also.

Dan




>
> The VM fix for 6898160 updates the jmm_GetVMGlobals function to filter 
> out unsupported type and the returning array may contain null 
> elements.  The sun.management.Flag class needs to check for null 
> elements and handle unsupported types gracefully.
>
> Thanks
> Mandy
>


From Mandy.Chung at Sun.COM  Tue Feb  9 05:36:12 2010
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Mon, 08 Feb 2010 21:36:12 -0800
Subject: Review request for 6924497:
	HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
In-Reply-To: <4B70EF0C.8000705@sun.com>
References: <4B70BD16.10908@sun.com> <4B70EF0C.8000705@sun.com>
Message-ID: <4B70F44C.8060002@sun.com>

Daniel D. Daugherty wrote:
> Mandy Chung wrote:
>> Dan,
>>
>> Can you review the fix for:
>>  6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
>>
>> Webrev at:
>>  http://cr.openjdk.java.net/~mchung/6924497/webrev.00/
> src/share/classes/sun/management/Flag.java
>    line 95 - I don't local var 'c' is needed here or on line 99.
>

It was used for verification.  It's no longer needed and I'll update it.
> src/share/native/sun/management/Flag.c
>    No comments.
>
Thanks for the review.

Mandy
> I'll be on the look  out for the VM fix also.
>
> Dan
>
>
>
>
>>
>> The VM fix for 6898160 updates the jmm_GetVMGlobals function to 
>> filter out unsupported type and the returning array may contain null 
>> elements.  The sun.management.Flag class needs to check for null 
>> elements and handle unsupported types gracefully.
>>
>> Thanks
>> Mandy
>>



From mandy.chung at sun.com  Tue Feb  9 18:51:12 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Tue, 09 Feb 2010 18:51:12 +0000
Subject: hg: jdk7/tl/jdk: 6924497:
	HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
Message-ID: <20100209185159.99056418BB@hg.openjdk.java.net>

Changeset: 83c34a6b1458
Author:    mchung
Date:      2010-02-08 23:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83c34a6b1458

6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE
Summary: Check if the element in the flags array is non-null to filter unsupported flags
Reviewed-by: dcubed

! src/share/classes/sun/management/Flag.java
! src/share/native/sun/management/Flag.c



From christopher.hegarty at sun.com  Wed Feb 10 14:41:42 2010
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Wed, 10 Feb 2010 14:41:42 +0000
Subject: hg: jdk7/tl/jdk: 6693244: Java Web Start app fails on 6u10 beta w/
	AssertionError in AuthenticationInfo.requestCompleted
Message-ID: <20100210144252.973AD419D9@hg.openjdk.java.net>

Changeset: ec438f2b6886
Author:    chegar
Date:      2010-02-10 13:23 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec438f2b6886

6693244: Java Web Start app fails on 6u10 beta w/ AssertionError in AuthenticationInfo.requestCompleted
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
! test/ProblemList.txt
! test/java/net/Authenticator/B4769350.java



From mandy.chung at sun.com  Thu Feb 11 03:05:27 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Thu, 11 Feb 2010 03:05:27 +0000
Subject: hg: jdk7/tl/jdk: 6915413: Module build: building of specified jdk
	components instead of all
Message-ID: <20100211030617.A5C4B41AAA@hg.openjdk.java.net>

Changeset: 784e52734b8d
Author:    mchung
Date:      2010-02-10 17:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/784e52734b8d

6915413: Module build: building of specified jdk components instead of all
Summary: Define new SUBDIRS_* variables for specifying components for one group
Reviewed-by: ohair

! make/Makefile
! make/com/Makefile
! make/com/sun/Makefile
! make/com/sun/demo/Makefile
! make/com/sun/demo/jvmti/Makefile
! make/com/sun/inputmethods/Makefile
! make/com/sun/java/Makefile
! make/com/sun/java/browser/Makefile
! make/com/sun/jmx/Makefile
! make/com/sun/jndi/Makefile
! make/com/sun/jndi/rmi/Makefile
! make/com/sun/nio/Makefile
! make/com/sun/org/Makefile
! make/com/sun/org/apache/Makefile
! make/com/sun/security/Makefile
! make/com/sun/tools/Makefile
! make/com/sun/tracing/Makefile
! make/common/Defs.gmk
! make/common/Sanity.gmk
+ make/common/Subdirs.gmk
! make/common/shared/Sanity.gmk
! make/java/Makefile
! make/java/hpi/Makefile
! make/java/java/Makefile
! make/java/java/genlocales.gmk
! make/java/main/Makefile
! make/java/nio/FILES_java.gmk
! make/java/nio/Makefile
+ make/java/nio/mxbean/Makefile
! make/java/redist/Makefile
- make/java/text/FILES_java.gmk
! make/java/text/Makefile
+ make/java/text/base/FILES_java.gmk
+ make/java/text/base/Makefile
+ make/java/text/bidi/Makefile
! make/javax/Makefile
! make/javax/rmi/Makefile
! make/javax/sound/Makefile
! make/javax/swing/Makefile
! make/jpda/Makefile
! make/jpda/transport/Makefile
! make/mkdemo/Makefile
! make/mkdemo/applets/Makefile
! make/mkdemo/jfc/Makefile
! make/mkdemo/jni/Makefile
! make/mkdemo/jvmti/Makefile
! make/mkdemo/management/Makefile
! make/mkdemo/scripting/Makefile
! make/mksample/Makefile
! make/mksample/jmx/Makefile
! make/mksample/nio/Makefile
! make/mksample/scripting/Makefile
! make/mksample/webservices/Makefile
! make/org/Makefile
! make/org/ietf/Makefile
! make/sun/Makefile
! make/sun/cmm/Makefile
! make/sun/image/Makefile
! make/sun/management/Makefile
! make/sun/net/Makefile
! make/sun/net/spi/Makefile
! make/sun/net/spi/nameservice/Makefile
! make/sun/nio/Makefile
! make/sun/org/Makefile
! make/sun/org/mozilla/Makefile
! make/sun/rmi/Makefile
! make/sun/security/Makefile
! make/sun/tracing/Makefile
! make/tools/Makefile



From weijun.wang at sun.com  Fri Feb 12 02:24:22 2010
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Fri, 12 Feb 2010 02:24:22 +0000
Subject: hg: jdk7/tl/jdk: 6925639: keytool -genkeypair -help missing dname
	option
Message-ID: <20100212022443.08E5E41C23@hg.openjdk.java.net>

Changeset: d7d8807fca86
Author:    weijun
Date:      2010-02-12 10:24 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d7d8807fca86

6925639: keytool -genkeypair -help missing dname option
Reviewed-by: mullan

! src/share/classes/sun/security/tools/KeyTool.java



From Mandy.Chung at Sun.COM  Fri Feb 12 05:44:09 2010
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Thu, 11 Feb 2010 21:44:09 -0800
Subject: Review request for 6925868: Eliminate pack200's dependency on logging
Message-ID: <4B74EAA9.5050805@sun.com>

Kumar or Alan,

Can you please review the fix for:
   6925868: Eliminate pack200's dependency on logging

Webrev at:
  http://cr.openjdk.java.net/~mchung/6925868/webrev.00/

The change is trivial.  It replaces the use of java.util.logging.Logger 
with its own wrapper class to call PlatformLogger.

Thanks
Mandy


From Alan.Bateman at Sun.COM  Fri Feb 12 08:59:45 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 12 Feb 2010 08:59:45 +0000
Subject: Review request for 6925868: Eliminate pack200's dependency on
	logging
In-Reply-To: <4B74EAA9.5050805@sun.com>
References: <4B74EAA9.5050805@sun.com>
Message-ID: <4B751881.4010701@sun.com>

Mandy Chung wrote:
> Kumar or Alan,
>
> Can you please review the fix for:
>   6925868: Eliminate pack200's dependency on logging
>
> Webrev at:
>  http://cr.openjdk.java.net/~mchung/6925868/webrev.00/
>
> The change is trivial.  It replaces the use of 
> java.util.logging.Logger with its own wrapper class to call 
> PlatformLogger.
>
> Thanks
> Mandy
Looks OK to me.

-Alan.


From forax at univ-mlv.fr  Fri Feb 12 09:04:09 2010
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 12 Feb 2010 10:04:09 +0100
Subject: Review request for 6925868: Eliminate pack200's dependency on
	logging
In-Reply-To: <4B751881.4010701@sun.com>
References: <4B74EAA9.5050805@sun.com> <4B751881.4010701@sun.com>
Message-ID: <4B751989.5050009@univ-mlv.fr>

Le 12/02/2010 09:59, Alan Bateman a ?crit :
> Mandy Chung wrote:
>> Kumar or Alan,
>>
>> Can you please review the fix for:
>>   6925868: Eliminate pack200's dependency on logging
>>
>> Webrev at:
>>  http://cr.openjdk.java.net/~mchung/6925868/webrev.00/
>>
>> The change is trivial.  It replaces the use of 
>> java.util.logging.Logger with its own wrapper class to call 
>> PlatformLogger.
>>
>> Thanks
>> Mandy
> Looks OK to me.
>
> -Alan.

No ok for me,
Pack200Logger.warning(String) goes to an infinite loop,
it should be:

public void warning(String msg) {
   getLogger().warning(msg);
}

R?mi




From Alan.Bateman at Sun.COM  Fri Feb 12 09:16:15 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 12 Feb 2010 09:16:15 +0000
Subject: Review request for 6925868: Eliminate pack200's dependency on
	logging
In-Reply-To: <4B751989.5050009@univ-mlv.fr>
References: <4B74EAA9.5050805@sun.com> <4B751881.4010701@sun.com>
	<4B751989.5050009@univ-mlv.fr>
Message-ID: <4B751C5F.8010904@sun.com>

R?mi Forax wrote:
> :
> No ok for me,
> Pack200Logger.warning(String) goes to an infinite loop,
> it should be:
>
> public void warning(String msg) {
>   getLogger().warning(msg);
> }
>
> R?mi
>
>
Well spotted!



From Mandy.Chung at Sun.COM  Fri Feb 12 16:13:22 2010
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Fri, 12 Feb 2010 08:13:22 -0800
Subject: Review request for 6925868: Eliminate pack200's dependency on
	logging
In-Reply-To: <4B751989.5050009@univ-mlv.fr>
References: <4B74EAA9.5050805@sun.com> <4B751881.4010701@sun.com>
	<4B751989.5050009@univ-mlv.fr>
Message-ID: <4B757E22.8020800@sun.com>

R?mi Forax wrote:
> No ok for me,

Sorry about putting an old webrev to cr.openjdk.java.net (forgot to 
update with the final one) .  In fact I fixed and ran the tests before 
sending out the review.
   http://cr.openjdk.java.net/~mchung/6925868/webrev.01/

Good spot.
Mandy

> Pack200Logger.warning(String) goes to an infinite loop,
> it should be:
>
> public void warning(String msg) {
>   getLogger().warning(msg);
> }
>
> R?mi
>
>



From mandy.chung at sun.com  Mon Feb 15 19:13:48 2010
From: mandy.chung at sun.com (mandy.chung at sun.com)
Date: Mon, 15 Feb 2010 19:13:48 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100215191427.C8872421FE@hg.openjdk.java.net>

Changeset: 74f493fae483
Author:    mchung
Date:      2010-02-12 11:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74f493fae483

6925868: Eliminate pack200's dependency on logging
Summary: Replace j.u.l.Logger with sun.util.logging.PlatformLogger
Reviewed-by: alanb, forax

! 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/Utils.java

Changeset: 328c5d3974fe
Author:    mchung
Date:      2010-02-15 10:18 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/328c5d3974fe

Merge




From jonathan.gibbons at sun.com  Tue Feb 16 00:11:30 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 16 Feb 2010 00:11:30 +0000
Subject: hg: jdk7/tl/langtools: 6926555: 6921979 breaks TreePosTest
Message-ID: <20100216001133.1261642256@hg.openjdk.java.net>

Changeset: 7d9e3a15d2b3
Author:    jjg
Date:      2010-02-15 16:09 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7d9e3a15d2b3

6926555: 6921979 breaks TreePosTest
Reviewed-by: darcy

! test/tools/javac/treepostests/TreePosTest.java



From joe.darcy at sun.com  Tue Feb 16 02:11:41 2010
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Tue, 16 Feb 2010 02:11:41 +0000
Subject: hg: jdk7/tl/langtools: 6634138: Source generated in last round not
	compiled
Message-ID: <20100216021143.DA5DE4227D@hg.openjdk.java.net>

Changeset: af18e3956985
Author:    darcy
Date:      2010-02-15 18:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/af18e3956985

6634138: Source generated in last round not compiled
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! test/tools/javac/T6403466.java
+ test/tools/javac/processing/6634138/Dummy.java
+ test/tools/javac/processing/6634138/ExerciseDependency.java
+ test/tools/javac/processing/6634138/T6634138.java



From joe.darcy at sun.com  Tue Feb 16 03:56:28 2010
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Tue, 16 Feb 2010 03:56:28 +0000
Subject: hg: jdk7/tl/langtools: 6926699: Annotation processing regression
	tests should typically return SourceVersion.latest
Message-ID: <20100216035631.067C042299@hg.openjdk.java.net>

Changeset: fe17a9dbef03
Author:    darcy
Date:      2010-02-15 20:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fe17a9dbef03

6926699: Annotation processing regression tests should typically return SourceVersion.latest
Reviewed-by: jjg

! test/tools/javac/6341866/Anno.java
! test/tools/javac/T6406771.java
! test/tools/javac/T6411379.java
! test/tools/javac/T6423583.java
! test/tools/javac/T6855236.java
! test/tools/javac/api/6421111/T6421111.java
! test/tools/javac/api/6468404/T6468404.java
! test/tools/javac/api/T6412669.java
! test/tools/javac/enum/6424358/T6424358.java
! test/tools/javac/processing/6348499/A.java
! test/tools/javac/processing/6414633/A.java
! test/tools/javac/processing/6430209/T6430209.java
! test/tools/javac/processing/6430209/b6341534.java
! test/tools/javac/processing/T6439826.java
! test/tools/javac/processing/model/element/TypeParamBounds.java
! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java
! test/tools/javac/processing/model/type/NoTypes.java
! test/tools/javac/processing/model/util/GetTypeElemBadArg.java
! test/tools/javac/processing/model/util/OverridesSpecEx.java



From joe.darcy at sun.com  Tue Feb 16 04:08:33 2010
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Tue, 16 Feb 2010 04:08:33 +0000
Subject: hg: jdk7/tl/langtools: 6926703: apt tests should run with assertions
	enabled
Message-ID: <20100216040836.364454229E@hg.openjdk.java.net>

Changeset: 631a273dac0f
Author:    darcy
Date:      2010-02-15 20:17 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/631a273dac0f

6926703: apt tests should run with assertions enabled
Reviewed-by: jjg

! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java



From joe.darcy at sun.com  Wed Feb 17 22:31:58 2010
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 17 Feb 2010 22:31:58 +0000
Subject: hg: jdk7/tl/langtools: 6927061: Refactor apt implemenation to use
	code from JSR 269
Message-ID: <20100217223204.DF32B42563@hg.openjdk.java.net>

Changeset: 16b9b7f45933
Author:    darcy
Date:      2010-02-17 14:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/16b9b7f45933

6927061: Refactor apt implemenation to use code from JSR 269
Reviewed-by: jjg

! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java
! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/main/Main.java
! src/share/classes/com/sun/tools/javac/file/Paths.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java



From lana.steuck at sun.com  Thu Feb 18 00:34:32 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 00:34:32 +0000
Subject: hg: jdk7/tl: 3 new changesets
Message-ID: <20100218003432.7888442588@hg.openjdk.java.net>

Changeset: e1176f86805f
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/e1176f86805f

Added tag jdk7-b81 for changeset 8403096d1fe7

! .hgtags

Changeset: 6880a3af9add
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/6880a3af9add

Added tag jdk7-b82 for changeset e1176f86805f

! .hgtags

Changeset: 2f3ea057d1ad
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/2f3ea057d1ad

Added tag jdk7-b83 for changeset 6880a3af9add

! .hgtags



From lana.steuck at sun.com  Thu Feb 18 00:34:39 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 00:34:39 +0000
Subject: hg: jdk7/tl/corba: 3 new changesets
Message-ID: <20100218003443.72C4142589@hg.openjdk.java.net>

Changeset: 1e8c1bfad1ab
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/1e8c1bfad1ab

Added tag jdk7-b81 for changeset e08a42a2a94d

! .hgtags

Changeset: fde0df7a2384
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/fde0df7a2384

Added tag jdk7-b82 for changeset 1e8c1bfad1ab

! .hgtags

Changeset: 68c8961a82e4
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/68c8961a82e4

Added tag jdk7-b83 for changeset fde0df7a2384

! .hgtags



From lana.steuck at sun.com  Thu Feb 18 00:36:23 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 00:36:23 +0000
Subject: hg: jdk7/tl/hotspot: 78 new changesets
Message-ID: <20100218004025.3B5B54258E@hg.openjdk.java.net>

Changeset: 2dd52dea6d28
Author:    johnc
Date:      2010-01-12 14:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2dd52dea6d28

6902115: G1:assert(ignore_max_completed||thread->is_Java_thread()||SafepointSynchronize::is_at_safepoint())
Summary: Remove invalid assert and mangle filler objects in TLABs that are being retired.
Reviewed-by: ysr, jmasa

! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/threadLocalAllocBuffer.cpp
! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp

Changeset: 7b0e9cba0307
Author:    ysr
Date:      2010-01-13 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7b0e9cba0307

6896647: card marks can be deferred too long
Summary: Deferred card marks are now flushed during the gc prologue. Parallel[Scavege,OldGC] and SerialGC no longer defer card marks generated by COMPILER2 as a result of ReduceInitialCardMarks. For these cases, introduced a diagnostic option to defer the card marks, only for the purposes of testing and diagnostics. CMS and G1 continue to defer card marks. Potential performance concern related to single-threaded flushing of deferred card marks in the gc prologue will be addressed in the future.
Reviewed-by: never, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 0c1bf505f7a2
Author:    tonyp
Date:      2010-01-13 15:46 -0500
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0c1bf505f7a2

6916652: G1: remove +UseG1GC from under experimental options
Summary: What the title says.
Reviewed-by: ysr, jmasa

! src/share/vm/runtime/globals.hpp

Changeset: 22e27cceb7d8
Author:    tonyp
Date:      2010-01-14 09:20 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22e27cceb7d8

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 09646c4656ca
Author:    johnc
Date:      2010-01-13 15:45 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09646c4656ca

6915005: G1: Hang in PtrQueueSet::completed_buffers_list_length with gcl001
Summary: When enqueuing a completed PtrQueue buffer, cache a local pointer to the buffer and clear the field in the PtrQueue prior to unlocking the mutex referenced by the _lock field and pass the cached local value to the enqueuing routine. This will prevent the same completed buffer being enqueued multiple times, which causes the hang.
Reviewed-by: ysr

! src/share/vm/gc_implementation/g1/ptrQueue.cpp
- src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp

Changeset: c4d722788ed6
Author:    ysr
Date:      2010-01-16 23:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c4d722788ed6

Merge

- src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 5b00c9feb9ea
Author:    trims
Date:      2010-01-19 14:23 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5b00c9feb9ea

Merge

- src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp

Changeset: b2b6a9bf6238
Author:    cfang
Date:      2010-01-12 14:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b2b6a9bf6238

6894779: Loop Predication for Loop Optimizer in C2
Summary: Loop predication implementation
Reviewed-by: never, kvn

! src/share/vm/includeDB_compiler2
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp

Changeset: 73b22f919c34
Author:    jrose
Date:      2010-01-13 23:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/73b22f919c34

6912065: final fields in objects need to support inlining optimizations for JSR 292
Reviewed-by: twisti, kvn

! src/share/vm/ci/ciField.cpp
! src/share/vm/runtime/globals.hpp

Changeset: ddb7834449d0
Author:    never
Date:      2010-01-15 11:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ddb7834449d0

6849984: Value methods for platform dependent math functions constant fold incorrectly
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/interpreter_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/interpreter/abstractInterpreter.hpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp

Changeset: 614b7e3a9f48
Author:    never
Date:      2010-01-15 16:15 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/614b7e3a9f48

6879943: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LIR.hpp:2029
Reviewed-by: kvn, cfang

! src/share/vm/c1/c1_LIR.hpp

Changeset: d11ce1551e8d
Author:    twisti
Date:      2010-01-18 05:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d11ce1551e8d

6917698: os::is_allocatable Zero fix for 32-bit platforms
Summary: Recent changes call os::is_allocatable which was not implemented in Zero.
Reviewed-by: twisti
Contributed-by: Edward Nevill <ed at camswl.com>

! src/os_cpu/linux_zero/vm/os_linux_zero.cpp

Changeset: acebf2655d3a
Author:    kvn
Date:      2010-01-19 10:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/acebf2655d3a

6917931: compiler/6895383/Test.java don't compile due missed imports
Summary: Add missing imports.
Reviewed-by: never, twisti

! test/compiler/6895383/Test.java

Changeset: 648fe315b257
Author:    kvn
Date:      2010-01-19 15:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/648fe315b257

6893701: compiler/6877254/Test.java fails because it combines -XX:+UseConcMarkSweepGC with other GC
Summary: Remove explicit GC flags in regression tests
Reviewed-by: never, ysr

! test/compiler/6877254/Test.java
! test/compiler/6896727/Test.java

Changeset: 3d6016e040d6
Author:    iveresov
Date:      2010-01-20 12:54 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3d6016e040d6

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 10f901469941
Author:    trims
Date:      2010-01-22 14:57 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/10f901469941

Merge


Changeset: 1f9b07674480
Author:    trims
Date:      2010-01-22 15:01 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f9b07674480

6919437: Bump the HS17 build number to 08
Summary: Update the HS17 build number to 08
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1999f5b12482
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1999f5b12482

Added tag jdk7-b81 for changeset 1f9b07674480

! .hgtags

Changeset: 26ecc6fa29e6
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26ecc6fa29e6

Added tag jdk7-b82 for changeset 1999f5b12482

! .hgtags

Changeset: 7fbf850d87b7
Author:    dcubed
Date:      2010-01-13 09:39 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7fbf850d87b7

6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining
Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter.
Reviewed-by: never, ohair, tbell, tdeneau
Contributed-by: Vasanth Venkatachalam <vasanth.venkatachalam at amd.com>

! make/Makefile
! make/defs.make
+ src/share/vm/code/jvmticmlr.h
! src/share/vm/includeDB_core
! src/share/vm/prims/jvmtiExport.cpp

Changeset: 3908ad124838
Author:    dcubed
Date:      2010-01-20 11:32 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3908ad124838

Merge

! make/Makefile
! make/defs.make
! src/share/vm/includeDB_core
! src/share/vm/prims/jvmtiExport.cpp

Changeset: 2718ec34c699
Author:    coleenp
Date:      2010-01-22 15:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2718ec34c699

Merge

- src/share/vm/gc_implementation/g1/ptrQueue.inline.hpp

Changeset: cf0685d550f1
Author:    never
Date:      2010-01-20 22:10 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cf0685d550f1

6911204: generated adapters with large signatures can fill up the code cache
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/includeDB_core
! src/share/vm/oops/methodOop.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 99af867dfa05
Author:    kvn
Date:      2010-01-26 08:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/99af867dfa05

6919886: Sweep CodeCache more aggressively to reduce its usage for CompileTheWorld
Summary: Add safepoint after CompileTheWorldSafepointInterval (100) compilations and do full sweep of CodeCache each time.
Reviewed-by: never
Contributed-by: eric.caspole at amd.com

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 89ca5ab4fa60
Author:    iveresov
Date:      2010-01-27 14:06 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/89ca5ab4fa60

Merge

! src/share/vm/includeDB_core

Changeset: 4788266644c1
Author:    jmasa
Date:      2010-01-21 11:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4788266644c1

6895236: CMS: cmsOopClosures.inline.hpp:43 assert(..., "Should remember klasses in this context")
Summary: Adjust assertion checking for ExplicitGCInvokesConcurrentAndUnloadsClasses as a reason for class unloading
Reviewed-by: ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/iterator.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp

Changeset: fed17682aea5
Author:    ysr
Date:      2010-01-21 14:47 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fed17682aea5

Merge


Changeset: 776fb94f33cc
Author:    apetrusenko
Date:      2010-01-21 18:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/776fb94f33cc

6918006: G1: spill space must be reserved on the stack for barrier calls on Windows x64
Summary: Stub code generated to call G1 barriers does not allocate spill space on the stack as required by Windows x64 ABI. The fix is to use more ABI-friendly call_VM_leaf().
Reviewed-by: iveresov, never, kvn

! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp

Changeset: c81fa70144aa
Author:    tonyp
Date:      2010-01-25 18:03 -0500
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c81fa70144aa

6919980: G1: remove +UseG1GC from under experimental options (second attempt)
Summary: Trying this again, as the original change was lost.
Reviewed-by: ysr, jmasa

! src/share/vm/runtime/globals.hpp

Changeset: 34fb2662f6c2
Author:    ysr
Date:      2010-01-26 16:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/34fb2662f6c2

6920090: G1: Disable ReduceInitialCardMarks at least until 6920109 is fixed
Summary: G1 now answers "no" to the query can_elide_initializing_store_barrier() in the product build. A debug flag allows alternate behaviour in debug builds.
Reviewed-by: iveresov, tonyp

! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_interface/collectedHeap.cpp

Changeset: 291c9b3b64fc
Author:    ysr
Date:      2010-01-26 23:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/291c9b3b64fc

Merge


Changeset: f3345b7b01b4
Author:    ysr
Date:      2010-01-27 22:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f3345b7b01b4

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 9e1637a04678
Author:    twisti
Date:      2010-01-28 08:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9e1637a04678

6920970: Zero build fixes after 6849984 and 6911204
Summary: Two recent commits broke the build on Zero.
Reviewed-by: twisti
Contributed-by: Gary Benson <gbenson at redhat.com>

! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp

Changeset: 8d9bfe6a446b
Author:    never
Date:      2010-01-28 16:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8d9bfe6a446b

6920346: G1: "must avoid base_memory and AliasIdxTop"
Reviewed-by: kvn

! src/share/vm/opto/memnode.hpp

Changeset: 0e14bd797dad
Author:    never
Date:      2010-01-28 20:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e14bd797dad

6792161: assert("No dead instructions after post-alloc")
Reviewed-by: kvn

! src/share/vm/opto/ifg.cpp
+ test/compiler/6792161/Test6792161.java

Changeset: ba263cfb7611
Author:    twisti
Date:      2010-01-29 12:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba263cfb7611

6917766: JSR 292 needs its own deopt handler
Summary: We need to introduce a new MH deopt handler so we can easily determine if the deopt happened at a MH call site or not.
Reviewed-by: never, jrose

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 24128c2ffa87
Author:    twisti
Date:      2010-01-29 08:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/24128c2ffa87

6921339: backout 6917766
Reviewed-by: mr

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 5f24d0319e54
Author:    kvn
Date:      2010-01-29 09:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5f24d0319e54

4360113: Evict nmethods when code cache gets full
Summary: Speculatively unload the oldest nmethods when code cache gets full.
Reviewed-by: never, kvn
Contributed-by: eric.caspole at amd.com

! src/share/vm/ci/ciEnv.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp

Changeset: 844a9d73ec22
Author:    never
Date:      2010-01-29 22:51 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/844a9d73ec22

6916644: C2 compiler crash on x86
Reviewed-by: kvn, twisti

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/machnode.hpp
! src/share/vm/opto/matcher.cpp
+ test/compiler/6916644/Test6916644.java

Changeset: 18a389214829
Author:    twisti
Date:      2010-02-01 19:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/18a389214829

6921352: JSR 292 needs its own deopt handler
Summary: We need to introduce a new MH deopt handler so we can easily determine if the deopt happened at a MH call site or not.
Reviewed-by: never, jrose

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.hpp
! src/cpu/x86/vm/frame_x86.inline.hpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 5fcfaa1ad96f
Author:    twisti
Date:      2010-02-01 23:18 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5fcfaa1ad96f

6921799: JSR 292 call sites should not be fixed-up
Summary: MethodHandle invoke call sites should not be fixed-up by SharedRuntime::fixup_callers_callsite as c2i/i2c adapters are used to implement MethodHandle actions.
Reviewed-by: kvn, never

! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 87684f1a88b5
Author:    kvn
Date:      2010-02-01 16:49 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87684f1a88b5

6614597: Performance variability in jvm2008 xml.validation
Summary: Fix incorrect marking of methods as not compilable.
Reviewed-by: never

! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/oops/methodDataOop.hpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/deoptimization.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 74c848d437ab
Author:    never
Date:      2010-02-03 12:28 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/74c848d437ab

6921922: fix for 6911204 breaks tagged stack interpreter
Reviewed-by: kvn

! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: cef333a48af6
Author:    kvn
Date:      2010-02-03 15:03 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cef333a48af6

6923043: failed nightly tests which use -XX:+PrintCompilation -Xcomp -XX:CompileOnly
Summary: Print "made not compilable" line  only for deoptimizations.
Reviewed-by: never

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/methodOop.cpp
! src/share/vm/oops/methodOop.hpp

Changeset: e8443c7be117
Author:    never
Date:      2010-02-03 15:56 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e8443c7be117

6921969: optimize 64 long multiply for case with high bits zero
Reviewed-by: never, twisti, kvn, rasbold
Contributed-by: Hiroshi Yamauchi <yamauchi at google.com>

! src/cpu/x86/vm/x86_32.ad
+ test/compiler/6921969/TestMultiplyLongHiZero.java

Changeset: 0fce83e8dc0e
Author:    never
Date:      2010-02-03 18:33 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0fce83e8dc0e

Merge


Changeset: c1f1137b3575
Author:    twisti
Date:      2010-02-04 03:34 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c1f1137b3575

Merge

! src/share/vm/runtime/globals.hpp

Changeset: c028504fdaa6
Author:    never
Date:      2010-02-04 11:16 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c028504fdaa6

6921992: failure in verify scheduling after 6792161
Reviewed-by: kvn

! src/share/vm/opto/ifg.cpp

Changeset: 6deeaebad47a
Author:    dcubed
Date:      2010-02-01 17:35 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6deeaebad47a

6902182: 4/4 Starting with jdwp agent should not incur performance penalty
Summary: Rename can_post_exceptions support to can_post_on_exceptions. Add support for should_post_on_exceptions flag to permit per JavaThread optimizations.
Reviewed-by: never, kvn, dcubed
Contributed-by: tom.deneau at amd.com

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jvmtiEventController.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiManageCapabilities.cpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: 0fc941df6fb7
Author:    dcubed
Date:      2010-02-02 10:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0fc941df6fb7

6918421: 1/1 in-process JVM now ignores preset Windows unhandled exception filter
Summary: Add support for chaining Windows UnhandledExceptionFilter handlers
Reviewed-by: kamg, dholmes, never, acorn, ikrylov

! src/os/windows/vm/os_windows.cpp

Changeset: f19bf22685cc
Author:    dcubed
Date:      2010-02-02 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f19bf22685cc

Merge

! src/os/windows/vm/os_windows.cpp

Changeset: 7f8790caccb0
Author:    apangin
Date:      2010-02-04 15:50 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7f8790caccb0

Merge

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: dba18cabafec
Author:    trims
Date:      2010-02-05 12:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dba18cabafec

Merge


Changeset: ff3232b68fbb
Author:    trims
Date:      2010-02-05 12:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ff3232b68fbb

6921473: Bump the HS17 build number to 09
Summary: Update the HS17 build number to 09
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 1e3c5d0474d4
Author:    trims
Date:      2010-02-05 16:21 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1e3c5d0474d4

Merge


Changeset: 39e0a32bc49b
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/39e0a32bc49b

Added tag hs17-b01 for changeset a94714c55065

! .hgtags

Changeset: bd1260aafd87
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bd1260aafd87

Added tag hs17-b02 for changeset faf94d94786b

! .hgtags

Changeset: d9c445aa7bb1
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d9c445aa7bb1

Added tag hs17-b03 for changeset f4b900403d6e

! .hgtags

Changeset: 3940517a1f13
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3940517a1f13

Added tag hs17-b04 for changeset d8dd291a362a

! .hgtags

Changeset: 4458e32d9125
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4458e32d9125

Added tag hs17-b05 for changeset 9174bb32e934

! .hgtags

Changeset: 36a78dac746f
Author:    trims
Date:      2010-02-11 19:52 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/36a78dac746f

Added tag hs17-b06 for changeset a5a6adfca6ec

! .hgtags

Changeset: bfa6d67a7a29
Author:    trims
Date:      2010-02-11 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bfa6d67a7a29

Added tag hs17-b07 for changeset 3003ddd1d433

! .hgtags

Changeset: 73047d0b13cf
Author:    trims
Date:      2010-02-11 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/73047d0b13cf

Added tag hs17-b08 for changeset 1f9b07674480

! .hgtags

Changeset: 12076a98a540
Author:    trims
Date:      2010-02-11 19:53 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/12076a98a540

Added tag hs17-b09 for changeset ff3232b68fbb

! .hgtags

Changeset: 704a172a0918
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/704a172a0918

Added tag hs16-b01 for changeset 981375ca07b7

! .hgtags

Changeset: e114a6374471
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e114a6374471

Added tag hs16-b02 for changeset f4cbf78110c7

! .hgtags

Changeset: 3469eafe9bf4
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3469eafe9bf4

Added tag hs16-b03 for changeset 07c1c01e0315

! .hgtags

Changeset: 26dba59fc9ec
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/26dba59fc9ec

Added tag hs16-b04 for changeset 08f86fa55a31

! .hgtags

Changeset: 8b0989046c93
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b0989046c93

Added tag hs16-b05 for changeset 32c83fb84370

! .hgtags

Changeset: 5fe06b3f6753
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5fe06b3f6753

Added tag hs16-b06 for changeset ba313800759b

! .hgtags

Changeset: 36ae83035b8e
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/36ae83035b8e

Added tag hs16-b07 for changeset 3c0f72981560

! .hgtags

Changeset: 89ef87b378cd
Author:    trims
Date:      2010-02-11 20:11 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/89ef87b378cd

Added tag hs16-b08 for changeset ac59d4e6dae5

! .hgtags

Changeset: cd89ef31a9c8
Author:    trims
Date:      2010-02-11 20:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd89ef31a9c8

Added tag hs15-b01 for changeset 3f844a28c5f4

! .hgtags

Changeset: 2099657b92a1
Author:    trims
Date:      2010-02-11 20:36 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2099657b92a1

Added tag hs15-b02 for changeset 1605bb4eb5a7

! .hgtags

Changeset: 9dcad51c5c70
Author:    trims
Date:      2010-02-11 20:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9dcad51c5c70

Added tag hs15-b03 for changeset 2581d90c6c9b

! .hgtags

Changeset: 07118aaebf50
Author:    trims
Date:      2010-02-11 20:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07118aaebf50

Added tag hs15-b04 for changeset 9ab385cb0c42

! .hgtags

Changeset: 3f370a32906e
Author:    trims
Date:      2010-02-11 20:37 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f370a32906e

Added tag hs15-b05 for changeset fafab5d5349c

! .hgtags

Changeset: ffc8d176b84b
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ffc8d176b84b

Added tag jdk7-b83 for changeset 3f370a32906e

! .hgtags



From lana.steuck at sun.com  Thu Feb 18 00:44:42 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 00:44:42 +0000
Subject: hg: jdk7/tl/jaxp: 5 new changesets
Message-ID: <20100218004442.D21114258F@hg.openjdk.java.net>

Changeset: c876ad22e4bf
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c876ad22e4bf

Added tag jdk7-b81 for changeset 204e59d488cd

! .hgtags

Changeset: 309a0a7fc6ce
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/309a0a7fc6ce

Added tag jdk7-b82 for changeset c876ad22e4bf

! .hgtags

Changeset: c664aff74b41
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c664aff74b41

Added tag jdk7-b83 for changeset 309a0a7fc6ce

! .hgtags

Changeset: bf7c7f2825ef
Author:    lana
Date:      2010-02-08 23:58 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bf7c7f2825ef

Merge


Changeset: 32c0cf01d555
Author:    lana
Date:      2010-02-14 23:35 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/32c0cf01d555

Merge




From lana.steuck at sun.com  Thu Feb 18 00:44:49 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 00:44:49 +0000
Subject: hg: jdk7/tl/jaxws: 3 new changesets
Message-ID: <20100218004449.BA4B242590@hg.openjdk.java.net>

Changeset: 31573ae8eed1
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/31573ae8eed1

Added tag jdk7-b81 for changeset f051045fe94a

! .hgtags

Changeset: 371e3ded591d
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/371e3ded591d

Added tag jdk7-b82 for changeset 31573ae8eed1

! .hgtags

Changeset: 8bc02839eee4
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/8bc02839eee4

Added tag jdk7-b83 for changeset 371e3ded591d

! .hgtags



From lana.steuck at sun.com  Thu Feb 18 00:47:29 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 00:47:29 +0000
Subject: hg: jdk7/tl/jdk: 38 new changesets
Message-ID: <20100218005921.BF53442594@hg.openjdk.java.net>

Changeset: 31ed4132f345
Author:    mikejwre
Date:      2010-01-28 11:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31ed4132f345

Added tag jdk7-b81 for changeset 10b993d417fc

! .hgtags

Changeset: b250e6c5a9e5
Author:    andrew
Date:      2010-01-28 21:01 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b250e6c5a9e5

6921068: Remove javadoc builds warnings from specdefault tag
Summary: Ignore specdefault tag to avoid javadoc warnings
Reviewed-by: darcy, ohair

! make/docs/Makefile

Changeset: b3b10d45778a
Author:    andrew
Date:      2010-01-29 02:38 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b3b10d45778a

6917466: Should set bootclasspath for javadoc in jdk build
Summary: javadoc needs to reference the newly built classes so as not to hit APIs which differ between the boot JDK and the source files of the JDK being built.
Reviewed-by: ohair

! make/common/shared/Defs-java.gmk
! make/javax/swing/beaninfo/SwingBeans.gmk

Changeset: 69ef657320ad
Author:    ohair
Date:      2010-01-29 09:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69ef657320ad

Merge


Changeset: 9027c6b9d7e2
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9027c6b9d7e2

Added tag jdk7-b82 for changeset 69ef657320ad

! .hgtags

Changeset: 9b82fa0505bc
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b82fa0505bc

Added tag jdk7-b83 for changeset 9027c6b9d7e2

! .hgtags

Changeset: e79d95ea2e81
Author:    lana
Date:      2010-02-08 23:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e79d95ea2e81

Merge


Changeset: 7e8c77ae401a
Author:    rkennke
Date:      2010-02-02 16:38 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e8c77ae401a

6888734: PIT: regression test fails when java.security.manager is enabled
Summary: Load FontManager instance in privileged block to avoid AccessControlException
Reviewed-by: igor, tdv

! src/share/classes/sun/font/FontManagerFactory.java
+ test/java/awt/PrintJob/Security/SecurityDialogTest.java
+ test/java/awt/PrintJob/Security/policy

Changeset: cedd0cdd5b9a
Author:    rkennke
Date:      2010-02-03 10:02 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cedd0cdd5b9a

6896335: GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in headless mode
Summary: Use local ge variable instead of localEnv field in GE.
Reviewed-by: igor, prr

! src/share/classes/java/awt/GraphicsEnvironment.java
+ test/java/awt/GraphicsEnvironment/TestGetDefScreenDevice.java

Changeset: 58d014485a29
Author:    rkennke
Date:      2010-02-07 11:07 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58d014485a29

6904882: java.awt.Font.createFont() causes AccessControlException if executed with "-Djava.security.manager"
Summary: Perform FontUtilities initialization in privileged block
Reviewed-by: igor, prr

! src/share/classes/sun/font/FontUtilities.java
+ test/java/awt/FontClass/FontPrivilege.java

Changeset: 89b0235188b5
Author:    lana
Date:      2010-02-09 00:00 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/89b0235188b5

Merge


Changeset: 31a3f28f3326
Author:    dcherepanov
Date:      2009-12-23 01:22 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31a3f28f3326

6908299: Missed changes for 6664512 during the merge with 6879044
Reviewed-by: mchung, art

! src/share/classes/sun/util/logging/PlatformLogger.java

Changeset: 7b65af04d43c
Author:    dav
Date:      2009-12-22 17:28 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7b65af04d43c

6893325: JComboBox and dragging to an item outside the bounds of the containing JFrame is not selecting that
Reviewed-by: art, dcherepanov

! src/solaris/classes/sun/awt/X11/XWindowPeer.java

Changeset: 26280d1705b2
Author:    dcherepanov
Date:      2009-12-28 20:35 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/26280d1705b2

6857363: deadlock caused by sun.awt.X11.XTrayIconPeer$Tooltip.display
Reviewed-by: ant, art

! src/solaris/classes/sun/awt/X11/InfoWindow.java

Changeset: fd5bf5955e37
Author:    uta
Date:      2009-12-24 17:19 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd5bf5955e37

4874070: invoking DragSource's startDrag with an Image renders no image on drag
Reviewed-by: art, denis, alexp

! make/sun/awt/FILES_c_windows.gmk
! make/sun/awt/Makefile
! make/sun/awt/make.depend
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
! src/windows/classes/sun/awt/windows/WDragSourceContextPeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/lib/flavormap.properties
! src/windows/native/sun/windows/awt.h
+ src/windows/native/sun/windows/awt_DCHolder.cpp
+ src/windows/native/sun/windows/awt_DCHolder.h
! src/windows/native/sun/windows/awt_DnDDS.cpp
! src/windows/native/sun/windows/awt_DnDDS.h
! src/windows/native/sun/windows/awt_DnDDT.cpp
! src/windows/native/sun/windows/awt_DnDDT.h
! src/windows/native/sun/windows/awt_Toolkit.cpp
! src/windows/native/sun/windows/awt_Toolkit.h
+ src/windows/native/sun/windows/awt_ole.cpp
+ src/windows/native/sun/windows/awt_ole.h
+ test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html
+ test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java
+ test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java
+ test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java
+ test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java
+ test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html
+ test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java
+ test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java
+ test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java
+ test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java
+ test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java
+ test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html
+ test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java
+ test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java
+ test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java
+ test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java
+ test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java
+ test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html
+ test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java
+ test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java
+ test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java

Changeset: 4799006d0171
Author:    uta
Date:      2010-01-13 17:10 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4799006d0171

Merge


Changeset: f154d4943a1a
Author:    uta
Date:      2010-01-14 17:56 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f154d4943a1a

6916867: Fastdebug build failed after CR 4874070 fix putback.
Reviewed-by: art, dcherepanov

! src/windows/native/sun/windows/awt_DnDDS.cpp

Changeset: 3cc5eff94552
Author:    dcherepanov
Date:      2010-01-20 01:33 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3cc5eff94552

6660258: Java application stops Windows logout/shutdown (regression in 1.5.0_14)
Reviewed-by: anthony, art, uta

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awtmsg.h

Changeset: 0f92194cd798
Author:    dcherepanov
Date:      2010-01-22 19:47 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f92194cd798

6756774: fstdebug jvm fails with assertion (result != deleted_handle(),"Used a deleted global handle.")
Reviewed-by: art, anthony

! src/windows/native/sun/windows/awt_MenuItem.cpp

Changeset: d7c4baff3f96
Author:    lana
Date:      2010-01-28 18:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d7c4baff3f96

Merge

- make/java/redist/FILES.gmk
! make/sun/awt/Makefile
- make/sun/nio/FILES_java.gmk
- src/share/classes/sun/dyn/util/BytecodeSignature.java
- src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java

Changeset: 66c193082586
Author:    yan
Date:      2010-02-08 17:02 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66c193082586

6882912: Strange behaviours when typing @ or '
Summary: Eliminate stray lines without a proper unicode->regularKeyID pair (e.g. as there is no "arrow left" unicode, should be no pair)
Reviewed-by: rupashka

! src/share/classes/sun/awt/ExtendedKeyCodes.java

Changeset: b51982678191
Author:    lana
Date:      2010-02-09 00:02 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b51982678191

Merge


Changeset: de7807599a9b
Author:    peytoia
Date:      2009-12-15 14:50 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de7807599a9b

5047314: [Col] Collator.compare() runs indefinitely for a certain set of Thai strings
Reviewed-by: okutsu

! src/share/classes/java/text/CollationElementIterator.java
+ test/java/text/Collator/Bug5047314.java

Changeset: 3efbbc00ac5f
Author:    lana
Date:      2009-12-16 16:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3efbbc00ac5f

Merge

- make/tools/CharsetMapping/DoubleByte-X.java
- make/tools/CharsetMapping/SingleByte-X.java
- src/share/classes/sun/awt/ComponentAccessor.java
- src/share/classes/sun/awt/WindowAccessor.java
- src/share/classes/sun/security/provider/IdentityDatabase.java
- src/share/classes/sun/security/provider/SystemIdentity.java
- src/share/classes/sun/security/provider/SystemSigner.java
- src/share/classes/sun/security/x509/X500Signer.java
- src/share/classes/sun/security/x509/X509Cert.java
- src/share/classes/sun/tools/jar/JarVerifierStream.java
- src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java
- src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java
- test/java/util/Formatter/Basic-X.java
- test/sun/tools/native2ascii/test2
- test/tools/launcher/SolarisDataModel.sh
- test/tools/launcher/SolarisRunpath.sh
- test/tools/launcher/libraryCaller.c
- test/tools/launcher/libraryCaller.h
- test/tools/launcher/libraryCaller.java

Changeset: e2f7e92c30f1
Author:    peterz
Date:      2009-12-21 19:26 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2f7e92c30f1

6860433: [Nimbus] Code to set a single slider's thumb background doesn't work as specified
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/nimbus/Defaults.template
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
+ test/javax/swing/plaf/nimbus/ColorCustomizationTest.java

Changeset: fffd21bc5657
Author:    peterz
Date:      2009-12-25 17:47 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fffd21bc5657

6860438: [Nimbus] Code to globally set slider's thumb background doesn't work as specified
Reviewed-by: rupashka

! src/share/classes/javax/swing/MultiUIDefaults.java
+ test/javax/swing/MultiUIDefaults/4300666/bug4300666.html
+ test/javax/swing/MultiUIDefaults/4300666/bug4300666.java
+ test/javax/swing/MultiUIDefaults/4331767/bug4331767.java
+ test/javax/swing/MultiUIDefaults/Test6860438.java

Changeset: e9ccd1dd6923
Author:    andrew
Date:      2010-01-08 12:51 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9ccd1dd6923

6584033: (tz) wrong buffer length in TimeZone_md.c
Summary: Add testcase for this bug
Reviewed-by: darcy, okutsu

+ test/java/util/TimeZone/TimeZoneDatePermissionCheck.java
+ test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh

Changeset: b129d0f7be40
Author:    peytoia
Date:      2010-01-13 15:40 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b129d0f7be40

6868503: RuleBasedBreakIterator is inefficient
Reviewed-by: okutsu

! src/share/classes/java/text/RuleBasedBreakIterator.java

Changeset: 9c5a24050392
Author:    malenkov
Date:      2010-01-21 21:45 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c5a24050392

4922835: DOC: Statement javadoc should indicate that target and methodName cannot be null
Reviewed-by: peterz

! src/share/classes/java/beans/Expression.java
! src/share/classes/java/beans/Statement.java

Changeset: eba0ff97a252
Author:    malenkov
Date:      2010-01-21 21:53 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eba0ff97a252

4968536: DOC: Javadoc for java.beans.Encoder.getPersistenceDelegate is incomplete
Reviewed-by: peterz

! src/share/classes/java/beans/Encoder.java

Changeset: 3c61edecf44f
Author:    okutsu
Date:      2010-01-26 15:42 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c61edecf44f

6912866: (date) java.util.Date.before / after may be expensive
Reviewed-by: peytoia

! src/share/classes/java/util/Date.java

Changeset: e7127f3fa2f4
Author:    peterz
Date:      2010-01-28 17:06 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e7127f3fa2f4

6912118: Incosistency in several SynthUI classes between inherited specs ofupdate() and paint() methods
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java
! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java
! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java
! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java
! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthListUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java
! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java
! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java
! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java
! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java
! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java
! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java

Changeset: 4eb3a8c95c24
Author:    malenkov
Date:      2010-01-28 20:49 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4eb3a8c95c24

6412286: DOC: LTP: Unspecified NPE in java.beans.DefaultPersistenceDelegate.instantiate method
Reviewed-by: peterz

! src/share/classes/java/beans/DefaultPersistenceDelegate.java
! src/share/classes/java/beans/PersistenceDelegate.java

Changeset: 3283bb8c1bcb
Author:    lana
Date:      2010-01-28 16:12 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3283bb8c1bcb

Merge

- make/java/redist/FILES.gmk
- make/sun/nio/FILES_java.gmk
- src/share/classes/sun/dyn/util/BytecodeSignature.java
- src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java

Changeset: 3913691b3021
Author:    malenkov
Date:      2010-02-05 10:36 +0300
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3913691b3021

6921057: REGRESSION: persistence delegate issue on Windows and Linux against 5.u23b03/6u17b11
Reviewed-by: peterz, art

! src/share/classes/java/beans/Introspector.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
! test/java/beans/Introspector/Test5102804.java
! test/java/beans/XMLEncoder/Test4646747.java

Changeset: 5c0c2882eed2
Author:    lana
Date:      2010-02-09 00:05 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5c0c2882eed2

Merge


Changeset: 7cb9388bb1a1
Author:    lana
Date:      2010-02-14 23:38 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7cb9388bb1a1

Merge


Changeset: 84792500750c
Author:    lana
Date:      2010-02-17 10:24 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84792500750c

Merge




From lana.steuck at sun.com  Thu Feb 18 01:03:05 2010
From: lana.steuck at sun.com (lana.steuck at sun.com)
Date: Thu, 18 Feb 2010 01:03:05 +0000
Subject: hg: jdk7/tl/langtools: 7 new changesets
Message-ID: <20100218010324.1DA7942596@hg.openjdk.java.net>

Changeset: 47003a3622f6
Author:    mikejwre
Date:      2010-01-28 11:27 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/47003a3622f6

Added tag jdk7-b81 for changeset cfabfcf9f110

! .hgtags

Changeset: c9f4ae1f1480
Author:    mikejwre
Date:      2010-02-04 11:19 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c9f4ae1f1480

Added tag jdk7-b82 for changeset 47003a3622f6

! .hgtags

Changeset: 2edcb5dc642d
Author:    mikejwre
Date:      2010-02-12 13:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2edcb5dc642d

Added tag jdk7-b83 for changeset c9f4ae1f1480

! .hgtags

Changeset: 56a46d079264
Author:    lana
Date:      2010-02-08 23:59 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/56a46d079264

Merge


Changeset: d9cd5b8286e4
Author:    lana
Date:      2010-02-14 23:39 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d9cd5b8286e4

Merge


Changeset: 67f0e05098fa
Author:    lana
Date:      2010-02-17 10:25 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/67f0e05098fa

Merge


Changeset: 0fce6b64c258
Author:    lana
Date:      2010-02-17 16:29 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0fce6b64c258

Merge




From jonathan.gibbons at sun.com  Thu Feb 18 23:43:11 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 18 Feb 2010 23:43:11 +0000
Subject: hg: jdk7/tl/langtools: 6927797:
	langtools/test/tools/javac/EarlyAssert.java fails when run with
	assertions enabled (-ea)
Message-ID: <20100218234319.C38B04270B@hg.openjdk.java.net>

Changeset: a3be81d385ee
Author:    jjg
Date:      2010-02-18 15:41 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a3be81d385ee

6927797: langtools/test/tools/javac/EarlyAssert.java fails when run with assertions enabled (-ea)
Reviewed-by: darcy

! test/tools/javac/EarlyAssert.java
+ test/tools/javac/EarlyAssertWrapper.java



From christopher.hegarty at sun.com  Mon Feb 22 16:03:14 2010
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Mon, 22 Feb 2010 16:03:14 +0000
Subject: hg: jdk7/tl/jdk: 6912868: "java.net.useSystemProxies" behavior fails
	to check "use_same_proxy" in GNOME
Message-ID: <20100222160419.D0C0842CC8@hg.openjdk.java.net>

Changeset: e83d9c0d5e95
Author:    chegar
Date:      2010-02-22 15:27 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e83d9c0d5e95

6912868: "java.net.useSystemProxies" behavior fails to check "use_same_proxy" in GNOME
Reviewed-by: alanb, chegar
Contributed-by: damjan.jov at gmail.com

! src/solaris/native/sun/net/spi/DefaultProxySelector.c
+ test/java/net/ProxySelector/SystemProxies.java



From ahughes at redhat.com  Mon Feb 22 21:37:25 2010
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Mon, 22 Feb 2010 21:37:25 +0000
Subject: hg: jdk7/tl/langtools: 6928623: Behaviour of VERBOSE=true on
	langtools build
Message-ID: <20100222213732.57AD342D21@hg.openjdk.java.net>

Changeset: f25efdb55c99
Author:    andrew
Date:      2010-02-22 21:37 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f25efdb55c99

6928623: Behaviour of VERBOSE=true on langtools build
Summary: VERBOSE=true causes -diagnostics to be passed to ant rather than -debug
Reviewed-by: jjg

! make/Makefile



From christopher.hegarty at sun.com  Tue Feb 23 17:08:59 2010
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Tue, 23 Feb 2010 17:08:59 +0000
Subject: hg: jdk7/tl/jdk: 6365587: Proxy-Connection header sent through tunnel
Message-ID: <20100223170941.5292F41403@hg.openjdk.java.net>

Changeset: c96d6cb31723
Author:    chegar
Date:      2010-02-23 17:08 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c96d6cb31723

6365587: Proxy-Connection header sent through tunnel
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java



From jonathan.gibbons at sun.com  Wed Feb 24 02:44:12 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 24 Feb 2010 02:44:12 +0000
Subject: hg: jdk7/tl/langtools: 6511613: javac unexpectedly doesn't fail in
	some cases if an annotation processor specified
Message-ID: <20100224024415.AA53C414A3@hg.openjdk.java.net>

Changeset: 6eca0895a644
Author:    jjg
Date:      2010-02-23 18:43 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6eca0895a644

6511613: javac unexpectedly doesn't fail in some cases if an annotation processor specified
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/util/Log.java
+ test/tools/javac/processing/6511613/DummyProcessor.java
+ test/tools/javac/processing/6511613/clss41701.java



From Joe.Darcy at Sun.COM  Wed Feb 24 03:37:43 2010
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Tue, 23 Feb 2010 19:37:43 -0800
Subject: Code review request to add @param <E> tags to various classes
Message-ID: <4B849F07.4080902@sun.com>

Hello.

Please review the patch below which adds missing "@param <E>" tags to 
document type variables in various types.

-Joe

--- old/src/share/classes/java/lang/Iterable.java    2010-02-23 
19:00:32.000000000 -0800
+++ new/src/share/classes/java/lang/Iterable.java    2010-02-23 
19:00:31.000000000 -0800
@@ -27,8 +27,12 @@
 
 import java.util.Iterator;
 
-/** Implementing this interface allows an object to be the target of
- *  the "foreach" statement.
+/**
+ * Implementing this interface allows an object to be the target of
+ * the "foreach" statement.
+ *
+ * @param <T> the type of elements returned by the iterator
+ *
  * @since 1.5
  */
 public interface Iterable<T> {
--- old/src/share/classes/java/util/Collection.java    2010-02-23 
19:00:33.000000000 -0800
+++ new/src/share/classes/java/util/Collection.java    2010-02-23 
19:00:32.000000000 -0800
@@ -103,6 +103,8 @@
  * <a href="{@docRoot}/../technotes/guides/collections/index.html">
  * Java Collections Framework</a>.
  *
+ * @param <E> the type of elements in this collection
+ *
  * @author  Josh Bloch
  * @author  Neal Gafter
  * @see     Set
--- old/src/share/classes/java/util/Iterator.java    2010-02-23 
19:00:34.000000000 -0800
+++ new/src/share/classes/java/util/Iterator.java    2010-02-23 
19:00:33.000000000 -0800
@@ -41,6 +41,8 @@
  * <a href="{@docRoot}/../technotes/guides/collections/index.html">
  * Java Collections Framework</a>.
  *
+ * @param <E> the type of elements returned by this iterator
+ *
  * @author  Josh Bloch
  * @see Collection
  * @see ListIterator
--- old/src/share/classes/java/util/List.java    2010-02-23 
19:00:35.000000000 -0800
+++ new/src/share/classes/java/util/List.java    2010-02-23 
19:00:34.000000000 -0800
@@ -89,6 +89,8 @@
  * <a href="{@docRoot}/../technotes/guides/collections/index.html">
  * Java Collections Framework</a>.
  *
+ * @param <E> the type of elements in this list
+ *
  * @author  Josh Bloch
  * @author  Neal Gafter
  * @see Collection



From martinrb at google.com  Wed Feb 24 04:53:44 2010
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 23 Feb 2010 20:53:44 -0800
Subject: Code review request to add @param <E> tags to various classes
In-Reply-To: <4B849F07.4080902@sun.com>
References: <4B849F07.4080902@sun.com>
Message-ID: <1ccfd1c11002232053ue87381dmd0b15434b87c4938@mail.gmail.com>

I agree that's it's a pretty good policy to have @params for all
type parameters.  Approved.

Martin

On Tue, Feb 23, 2010 at 19:37, Joe Darcy <Joe.Darcy at sun.com> wrote:
> Hello.
>
> Please review the patch below which adds missing "@param <E>" tags to
> document type variables in various types.
>
> -Joe
>
> --- old/src/share/classes/java/lang/Iterable.java ? ?2010-02-23
> 19:00:32.000000000 -0800
> +++ new/src/share/classes/java/lang/Iterable.java ? ?2010-02-23
> 19:00:31.000000000 -0800
> @@ -27,8 +27,12 @@
>
> import java.util.Iterator;
>
> -/** Implementing this interface allows an object to be the target of
> - * ?the "foreach" statement.
> +/**
> + * Implementing this interface allows an object to be the target of
> + * the "foreach" statement.
> + *
> + * @param <T> the type of elements returned by the iterator
> + *
> ?* @since 1.5
> ?*/
> public interface Iterable<T> {
> --- old/src/share/classes/java/util/Collection.java ? ?2010-02-23
> 19:00:33.000000000 -0800
> +++ new/src/share/classes/java/util/Collection.java ? ?2010-02-23
> 19:00:32.000000000 -0800
> @@ -103,6 +103,8 @@
> ?* <a href="{@docRoot}/../technotes/guides/collections/index.html">
> ?* Java Collections Framework</a>.
> ?*
> + * @param <E> the type of elements in this collection
> + *
> ?* @author ?Josh Bloch
> ?* @author ?Neal Gafter
> ?* @see ? ? Set
> --- old/src/share/classes/java/util/Iterator.java ? ?2010-02-23
> 19:00:34.000000000 -0800
> +++ new/src/share/classes/java/util/Iterator.java ? ?2010-02-23
> 19:00:33.000000000 -0800
> @@ -41,6 +41,8 @@
> ?* <a href="{@docRoot}/../technotes/guides/collections/index.html">
> ?* Java Collections Framework</a>.
> ?*
> + * @param <E> the type of elements returned by this iterator
> + *
> ?* @author ?Josh Bloch
> ?* @see Collection
> ?* @see ListIterator
> --- old/src/share/classes/java/util/List.java ? ?2010-02-23
> 19:00:35.000000000 -0800
> +++ new/src/share/classes/java/util/List.java ? ?2010-02-23
> 19:00:34.000000000 -0800
> @@ -89,6 +89,8 @@
> ?* <a href="{@docRoot}/../technotes/guides/collections/index.html">
> ?* Java Collections Framework</a>.
> ?*
> + * @param <E> the type of elements in this list
> + *
> ?* @author ?Josh Bloch
> ?* @author ?Neal Gafter
> ?* @see Collection
>
>


From alan.bateman at sun.com  Wed Feb 24 09:57:56 2010
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Wed, 24 Feb 2010 09:57:56 +0000
Subject: hg: jdk7/tl/jdk: 4 new changesets
Message-ID: <20100224095911.499924152A@hg.openjdk.java.net>

Changeset: 38fbb2353a6a
Author:    alanb
Date:      2010-02-23 17:56 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38fbb2353a6a

6925977: (file) test/java/nio/file/Path/CheckPermissions.java fails if test.src on read-only file system
Reviewed-by: chegar

! test/java/nio/file/Path/CheckPermissions.java

Changeset: 00abf8c232be
Author:    alanb
Date:      2010-02-23 17:58 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/00abf8c232be

6925932: (file) Path.endsWith can throw ArrayIndexOutOfBoundsException (unx)
Reviewed-by: chegar

! src/solaris/classes/sun/nio/fs/UnixPath.java
! test/java/nio/file/Path/PathOps.java

Changeset: be5db597f3be
Author:    alanb
Date:      2010-02-23 18:19 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be5db597f3be

6928960: make modules fails to build class analyzer
Reviewed-by: mchung

! make/modules/tools/Makefile

Changeset: e94b296b53b4
Author:    alanb
Date:      2010-02-23 18:21 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e94b296b53b4

6926800: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with newer versions of find(1)
Reviewed-by: forax

! test/java/nio/file/Files/PrintFileTree.java
! test/java/nio/file/Files/walk_file_tree.sh



From joe.darcy at sun.com  Wed Feb 24 18:49:13 2010
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 24 Feb 2010 18:49:13 +0000
Subject: hg: jdk7/tl/jdk: 6929382: Various core classes in util and elsewhere
	are missing @param <T> tags
Message-ID: <20100224184932.478AE415E8@hg.openjdk.java.net>

Changeset: e842e99b514a
Author:    darcy
Date:      2010-02-24 10:48 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e842e99b514a

6929382: Various core classes in util and elsewhere are missing @param <T> tags
Reviewed-by: dholmes, martin

! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java



From xuelei.fan at sun.com  Thu Feb 25 06:13:28 2010
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Thu, 25 Feb 2010 06:13:28 +0000
Subject: hg: jdk7/tl/jdk: 6916202: More cases of invalid ldap filters accepted
	and processed
Message-ID: <20100225061347.A1F03416C0@hg.openjdk.java.net>

Changeset: 9929203a8b98
Author:    xuelei
Date:      2010-02-25 13:32 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9929203a8b98

6916202: More cases of invalid ldap filters accepted and processed
Reviewed-by: vinnie, weijun

! src/share/classes/com/sun/jndi/ldap/Filter.java
+ test/com/sun/jndi/ldap/InvalidLdapFilters.java



From Vladimir.Yaroslavskiy at Sun.COM  Thu Feb 25 15:25:07 2010
From: Vladimir.Yaroslavskiy at Sun.COM (Vladimir Yaroslavskiy)
Date: Thu, 25 Feb 2010 18:25:07 +0300
Subject: Format changes in source code of Dual-Pivot Quicksort: removing of
	double spaces
Message-ID: <4B869653.7030902@Sun.COM>

Hello,

The Dual-Pivot Quicksort source code contains several
double spaces and it would be nice to remove them, the
changes in DualPivotQuicksort class are pretty trivial:

1. ... is empty  and the call is ...
                ^^
2. ... // (a[k] > pivot1) -  Move a[k] to right part ...
                            ^^
The diff is here:
http://cr.openjdk.java.net/~alanb/6929259/webrev.00

Note that white space changes are usually ignored by
webrev so the patch file is the place to see the change.

Thank you,
Vladimir


From jonathan.gibbons at sun.com  Thu Feb 25 17:44:27 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 25 Feb 2010 17:44:27 +0000
Subject: hg: jdk7/tl/langtools: 4880220: Add a warning when accessing a static
	method via an reference
Message-ID: <20100225174430.2B9114177B@hg.openjdk.java.net>

Changeset: 87eb6edd4f21
Author:    jjg
Date:      2010-02-25 09:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/87eb6edd4f21

4880220: Add a warning when accessing a static method via an reference
Reviewed-by: darcy

! make/build.properties
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/4880220/T4880220.empty.out
+ test/tools/javac/4880220/T4880220.error.out
+ test/tools/javac/4880220/T4880220.java
+ test/tools/javac/4880220/T4880220.warn.out



From Alan.Bateman at Sun.COM  Thu Feb 25 17:51:32 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 25 Feb 2010 17:51:32 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
Message-ID: <4B86B8A4.8050709@sun.com>


There are two fixes in Sun's proprietary jdk6 updates that should also 
be fixed in OpenJDK.

The first one is that the File.getXXXSpace methods use statvfs instead 
of statvfs64 and so fail on 32-bit Solaris and Linux with very large 
file systems. The webrev is here:
  http://cr.openjdk.java.net/~alanb/6815768/webrev.00/
The GetXSpace test already covers these methods and an additional test 
isn't required.

The second one is a scalability fix to String.hashCode to avoid storing 
the hash code of empty strings. The webrev with the change is here:
  http://cr.openjdk.java.net/~alanb/6815768/webrev/

Thanks,
Alan.


From Alan.Bateman at Sun.COM  Thu Feb 25 17:56:02 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 25 Feb 2010 17:56:02 +0000
Subject: Format changes in source code of Dual-Pivot Quicksort: removing of
	double spaces
In-Reply-To: <4B869653.7030902@Sun.COM>
References: <4B869653.7030902@Sun.COM>
Message-ID: <4B86B9B2.7010200@sun.com>

Vladimir Yaroslavskiy wrote:
> Hello,
>
> The Dual-Pivot Quicksort source code contains several
> double spaces and it would be nice to remove them, the
> changes in DualPivotQuicksort class are pretty trivial:
>
> 1. ... is empty  and the call is ...
>                ^^
> 2. ... // (a[k] > pivot1) -  Move a[k] to right part ...
>                            ^^
> The diff is here:
> http://cr.openjdk.java.net/~alanb/6929259/webrev.00
>
> Note that white space changes are usually ignored by
> webrev so the patch file is the place to see the change.
>
> Thank you,
> Vladimir
Looks OK to me and I can push this for you.

-Alan


From Kelly.Ohair at Sun.COM  Thu Feb 25 18:19:26 2010
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 25 Feb 2010 10:19:26 -0800
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B86B8A4.8050709@sun.com>
References: <4B86B8A4.8050709@sun.com>
Message-ID: <4B86BF2E.8030208@sun.com>

Looks fine to me.

-kto

On 2/25/10 9:51 AM, Alan Bateman wrote:
>
> There are two fixes in Sun's proprietary jdk6 updates that should also
> be fixed in OpenJDK.
>
> The first one is that the File.getXXXSpace methods use statvfs instead
> of statvfs64 and so fail on 32-bit Solaris and Linux with very large
> file systems. The webrev is here:
> http://cr.openjdk.java.net/~alanb/6815768/webrev.00/
> The GetXSpace test already covers these methods and an additional test
> isn't required.
>
> The second one is a scalability fix to String.hashCode to avoid storing
> the hash code of empty strings. The webrev with the change is here:
> http://cr.openjdk.java.net/~alanb/6815768/webrev/
>
> Thanks,
> Alan.


From gnu_andrew at member.fsf.org  Thu Feb 25 18:58:35 2010
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 25 Feb 2010 18:58:35 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 
	6815768 (String.hashCode)
In-Reply-To: <4B86BF2E.8030208@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
Message-ID: <17c6771e1002251058xaef3cf4qeab936ce1fa75ef6@mail.gmail.com>

On 25 February 2010 18:19, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> Looks fine to me.
>
> -kto
>
> On 2/25/10 9:51 AM, Alan Bateman wrote:
>>
>> There are two fixes in Sun's proprietary jdk6 updates that should also
>> be fixed in OpenJDK.
>>
>> The first one is that the File.getXXXSpace methods use statvfs instead
>> of statvfs64 and so fail on 32-bit Solaris and Linux with very large
>> file systems. The webrev is here:
>> http://cr.openjdk.java.net/~alanb/6815768/webrev.00/
>> The GetXSpace test already covers these methods and an additional test
>> isn't required.
>>
>> The second one is a scalability fix to String.hashCode to avoid storing
>> the hash code of empty strings. The webrev with the change is here:
>> http://cr.openjdk.java.net/~alanb/6815768/webrev/
>>
>> Thanks,
>> Alan.
>

Joe, ok for 6 too?
-- 
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 joe.darcy at sun.com  Thu Feb 25 19:04:54 2010
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 25 Feb 2010 19:04:54 +0000
Subject: hg: jdk7/tl/langtools: 6929645: Address various findbugs warnings in
	langtools
Message-ID: <20100225190457.3A42541793@hg.openjdk.java.net>

Changeset: 85242c273d31
Author:    darcy
Date:      2010-02-25 11:04 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/85242c273d31

6929645: Address various findbugs warnings in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java



From Alan.Bateman at Sun.COM  Thu Feb 25 19:08:53 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 25 Feb 2010 19:08:53 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B86BF2E.8030208@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
Message-ID: <4B86CAC5.4050405@sun.com>

Kelly O'Hair wrote:
> Looks fine to me.
>
> -kto
Thanks Kelly and also to Joe for pointing out that I botched the link to 
the second one - here is the right webrev:
  http://cr.openjdk.java.net/~alanb/6921374/webrev/

-Alan




From Xueming.Shen at Sun.COM  Thu Feb 25 19:09:28 2010
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 25 Feb 2010 11:09:28 -0800
Subject: Codereview needed for #6929479
Message-ID: <4B86CAE8.3080008@sun.com>


http://cr.openjdk.java.net/~sherman/6929479/webrev/

This is a rfe to add a system property sun.zip.disableMmap to enable the 
end user to disable the mmap usage in
Sun's java.util.zip.ZipFile implementaiton (for Solaris and Linux 
platforms).

Application uses java.util.zip.ZipFile might experience SIGBUS vm crash 
if the application mistakely over-writes
zip/jar files that are still being used, for example the application 
server repeatedly deploy the same jar file into the
same location again and again while there is still code (running in the 
same vm)  still accessing this particular zip/
jar file (access the memory that mmapped the central directory of the 
zip file). While this is indeed an programming
error in the offending application, there is situation that the end user 
really does not have the control of those
applications and look for a workaround for the crash. With this property 
set to true (-Dsun.zip.disableMmap=true)
the sun zipfile implementation reads in the central directory into the 
memory instead of using mmap.

Thanks,
Sherman


From Kelly.Ohair at Sun.COM  Thu Feb 25 19:33:32 2010
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 25 Feb 2010 11:33:32 -0800
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B86CAC5.4050405@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com>
Message-ID: <4B86D08C.7090309@sun.com>

DOH! Yeah that one looks better... ;^)
Thought they looked the same before.

-kto


On 2/25/10 11:08 AM, Alan Bateman wrote:
> Kelly O'Hair wrote:
>> Looks fine to me.
>>
>> -kto
> Thanks Kelly and also to Joe for pointing out that I botched the link to
> the second one - here is the right webrev:
> http://cr.openjdk.java.net/~alanb/6921374/webrev/
>
> -Alan
>
>


From Alan.Bateman at Sun.COM  Thu Feb 25 19:49:17 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 25 Feb 2010 19:49:17 +0000
Subject: Codereview needed for #6929479
In-Reply-To: <4B86CAE8.3080008@sun.com>
References: <4B86CAE8.3080008@sun.com>
Message-ID: <4B86D43D.4000002@sun.com>

Xueming Shen wrote:
>
> http://cr.openjdk.java.net/~sherman/6929479/webrev/
>
> This is a rfe to add a system property sun.zip.disableMmap to enable 
> the end user to disable the mmap usage in
> Sun's java.util.zip.ZipFile implementaiton (for Solaris and Linux 
> platforms).
>
> Application uses java.util.zip.ZipFile might experience SIGBUS vm 
> crash if the application mistakely over-writes
> zip/jar files that are still being used, for example the application 
> server repeatedly deploy the same jar file into the
> same location again and again while there is still code (running in 
> the same vm)  still accessing this particular zip/
> jar file (access the memory that mmapped the central directory of the 
> zip file). While this is indeed an programming
> error in the offending application, there is situation that the end 
> user really does not have the control of those
> applications and look for a workaround for the crash. With this 
> property set to true (-Dsun.zip.disableMmap=true)
> the sun zipfile implementation reads in the central directory into the 
> memory instead of using mmap.
I've had to debug a few of these so this option should be very useful. I 
wonder if sun.zip.disableMapping would be a slightly better name?

The changes looks reasonable to me - it's just a pity that we can't get 
rid of USE_MMAP (the changes really make this stand out).

-Alan


From Xueming.Shen at Sun.COM  Thu Feb 25 20:00:04 2010
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 25 Feb 2010 12:00:04 -0800
Subject: Codereview needed for #6929479
In-Reply-To: <4B86D43D.4000002@sun.com>
References: <4B86CAE8.3080008@sun.com> <4B86D43D.4000002@sun.com>
Message-ID: <4B86D6C4.4080600@sun.com>

Alan Bateman wrote:
> Xueming Shen wrote:
>>
>> http://cr.openjdk.java.net/~sherman/6929479/webrev/
>>
>> This is a rfe to add a system property sun.zip.disableMmap to enable 
>> the end user to disable the mmap usage in
>> Sun's java.util.zip.ZipFile implementaiton (for Solaris and Linux 
>> platforms).
>>
>> Application uses java.util.zip.ZipFile might experience SIGBUS vm 
>> crash if the application mistakely over-writes
>> zip/jar files that are still being used, for example the application 
>> server repeatedly deploy the same jar file into the
>> same location again and again while there is still code (running in 
>> the same vm)  still accessing this particular zip/
>> jar file (access the memory that mmapped the central directory of the 
>> zip file). While this is indeed an programming
>> error in the offending application, there is situation that the end 
>> user really does not have the control of those
>> applications and look for a workaround for the crash. With this 
>> property set to true (-Dsun.zip.disableMmap=true)
>> the sun zipfile implementation reads in the central directory into 
>> the memory instead of using mmap.
> I've had to debug a few of these so this option should be very useful. 
> I wonder if sun.zip.disableMapping would be a slightly better name?

The webrev has been updated to use "sun.zip.disableMmapping", I guess 
you meant "sun.zip.disableMmapping", right?

Sherman

>
> The changes looks reasonable to me - it's just a pity that we can't 
> get rid of USE_MMAP (the changes really make this stand out).
>
> -Alan



From Alan.Bateman at Sun.COM  Thu Feb 25 20:02:43 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 25 Feb 2010 20:02:43 +0000
Subject: Codereview needed for #6929479
In-Reply-To: <4B86D6C4.4080600@sun.com>
References: <4B86CAE8.3080008@sun.com> <4B86D43D.4000002@sun.com>
	<4B86D6C4.4080600@sun.com>
Message-ID: <4B86D763.8080603@sun.com>

Xueming Shen wrote:
> :
> The webrev has been updated to use "sun.zip.disableMmapping", I guess 
> you meant "sun.zip.disableMmapping", right?
It's hard to find a good name. I was suggesting disableMapping (no 
double m) but disableMemoryMapping could work too.

-Alan.


From Lance.Andersen at Sun.COM  Thu Feb 25 20:09:08 2010
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 25 Feb 2010 15:09:08 -0500
Subject: Codereview needed for #6929479
In-Reply-To: <4B86D763.8080603@sun.com>
References: <4B86CAE8.3080008@sun.com> <4B86D43D.4000002@sun.com>
	<4B86D6C4.4080600@sun.com> <4B86D763.8080603@sun.com>
Message-ID: <4B86D8E4.2030001@sun.com>

Going forward, should we be using sun or oracle in the property names?

-lance

Alan Bateman wrote:
> Xueming Shen wrote:
>> :
>> The webrev has been updated to use "sun.zip.disableMmapping", I guess 
>> you meant "sun.zip.disableMmapping", right?
> It's hard to find a good name. I was suggesting disableMapping (no 
> double m) but disableMemoryMapping could work too.
>
> -Alan.


From Ulf.Zibis at gmx.de  Thu Feb 25 20:17:37 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 25 Feb 2010 21:17:37 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B86CAC5.4050405@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com>
Message-ID: <4B86DAE1.5050208@gmx.de>

Why don't you use the faster local copy of count for the junction like:

    if (h == 0&&  len>  0) {

?

-Ulf



Am 25.02.2010 20:08, schrieb Alan Bateman:
> Kelly O'Hair wrote:
>> Looks fine to me.
>>
>> -kto
> Thanks Kelly and also to Joe for pointing out that I botched the link 
> to the second one - here is the right webrev:
>  http://cr.openjdk.java.net/~alanb/6921374/webrev/
>
> -Alan
>
>
>



From Kelly.Ohair at Sun.COM  Thu Feb 25 20:21:48 2010
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 25 Feb 2010 12:21:48 -0800
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B86DAE1.5050208@gmx.de>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
Message-ID: <4B86DBDC.9090703@sun.com>

Yup.  My eyes must be tired, I didn't see that. :^(

-kto

On 2/25/10 12:17 PM, Ulf Zibis wrote:
> Why don't you use the faster local copy of count for the junction like:
>
> if (h == 0&& len> 0) {
>
> ?
>
> -Ulf
>
>
>
> Am 25.02.2010 20:08, schrieb Alan Bateman:
>> Kelly O'Hair wrote:
>>> Looks fine to me.
>>>
>>> -kto
>> Thanks Kelly and also to Joe for pointing out that I botched the link
>> to the second one - here is the right webrev:
>> http://cr.openjdk.java.net/~alanb/6921374/webrev/
>>
>> -Alan
>>
>>
>>
>


From jonathan.gibbons at sun.com  Thu Feb 25 20:27:45 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 25 Feb 2010 20:27:45 +0000
Subject: hg: jdk7/tl/langtools: 6929544: langtools source code uses statics
	qualified by instance variables
Message-ID: <20100225202748.28FA1417AB@hg.openjdk.java.net>

Changeset: dbcba45123cd
Author:    jjg
Date:      2010-02-25 12:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dbcba45123cd

6929544: langtools source code uses statics qualified by instance variables
Reviewed-by: darcy

! make/build.properties
! src/share/classes/com/sun/tools/apt/main/CommandLine.java
! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java
! src/share/classes/com/sun/tools/doclets/standard/Standard.java
! src/share/classes/com/sun/tools/javac/Launcher.java
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
! src/share/classes/com/sun/tools/javac/main/CommandLine.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java



From jonathan.gibbons at sun.com  Thu Feb 25 21:33:31 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 25 Feb 2010 21:33:31 +0000
Subject: hg: jdk7/tl/langtools: 6893943: exit code from javah with no args is 0
Message-ID: <20100225213334.1F0A4417BD@hg.openjdk.java.net>

Changeset: af75fd6155de
Author:    jjg
Date:      2010-02-25 13:32 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/af75fd6155de

6893943: exit code from javah with no args is 0
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javah/JavahTask.java
+ test/tools/javah/T6893943.java



From Alan.Bateman at Sun.COM  Thu Feb 25 22:07:12 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Thu, 25 Feb 2010 22:07:12 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B86DBDC.9090703@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<4B86DBDC.9090703@sun.com>
Message-ID: <4B86F490.60704@sun.com>

Kelly O'Hair wrote:
> Yup.  My eyes must be tired, I didn't see that. :^(
Too many repositories in the air at the same time. The webrev has been 
refreshed. Thanks Ulf.


From jason_mehrens at hotmail.com  Thu Feb 25 22:23:41 2010
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 25 Feb 2010 16:23:41 -0600
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B86DAE1.5050208@gmx.de>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>, <4B86CAC5.4050405@sun.com>,
	<4B86DAE1.5050208@gmx.de>
Message-ID: <SNT114-W1F6BA90892B5059181C1183400@phx.gbl>


Alan,

 

Shouldn't the loading of 'this.count' into 'len' be only performed if 'h' is zero?  Otherwise, when hash is not zero we perform a little unnecessary work every time hashCode is called.

 

Jason
 
> Date: Thu, 25 Feb 2010 21:17:37 +0100
> From: Ulf.Zibis at gmx.de
> To: Alan.Bateman at Sun.COM
> Subject: Re: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)
> CC: core-libs-dev at openjdk.java.net; Kelly.Ohair at Sun.COM
> 
> Why don't you use the faster local copy of count for the junction like:
> 
> if (h == 0&& len> 0) {
> 
> ?
> 
> -Ulf
> 
> 
> 
> Am 25.02.2010 20:08, schrieb Alan Bateman:
> > Kelly O'Hair wrote:
> >> Looks fine to me.
> >>
> >> -kto
> > Thanks Kelly and also to Joe for pointing out that I botched the link 
> > to the second one - here is the right webrev:
> > http://cr.openjdk.java.net/~alanb/6921374/webrev/
> >
> > -Alan
> >
> >
> >
> 
 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100225/dc8fda27/attachment.html>

From Joe.Darcy at Sun.COM  Fri Feb 26 00:04:04 2010
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 25 Feb 2010 16:04:04 -0800
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <17c6771e1002251058xaef3cf4qeab936ce1fa75ef6@mail.gmail.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<17c6771e1002251058xaef3cf4qeab936ce1fa75ef6@mail.gmail.com>
Message-ID: <4B870FF4.4020101@sun.com>

Andrew John Hughes wrote:
> On 25 February 2010 18:19, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>   
>> Looks fine to me.
>>
>> -kto
>>
>> On 2/25/10 9:51 AM, Alan Bateman wrote:
>>     
>>> There are two fixes in Sun's proprietary jdk6 updates that should also
>>> be fixed in OpenJDK.
>>>
>>> The first one is that the File.getXXXSpace methods use statvfs instead
>>> of statvfs64 and so fail on 32-bit Solaris and Linux with very large
>>> file systems. The webrev is here:
>>> http://cr.openjdk.java.net/~alanb/6815768/webrev.00/
>>> The GetXSpace test already covers these methods and an additional test
>>> isn't required.
>>>
>>> The second one is a scalability fix to String.hashCode to avoid storing
>>> the hash code of empty strings. The webrev with the change is here:
>>> http://cr.openjdk.java.net/~alanb/6815768/webrev/
>>>
>>> Thanks,
>>> Alan.
>>>       
>
> Joe, ok for 6 too?
>   

Yes, whatever versions of these fixes end up in JDK 7 can also be 
applied to OpenJDK 6.

-Joe


From Xueming.Shen at Sun.COM  Fri Feb 26 00:10:25 2010
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 25 Feb 2010 16:10:25 -0800
Subject: Codereview needed for HKSCS2008 support in JDK7
Message-ID: <4B871171.8060809@sun.com>

Alan, Martin, Masayoshi and anyone interested, please help comment and 
review.

Bugs/RFEs:
6911753: NSN wants to add Big5 HKSCS-2004 support
6902790: Converting/displaying HKSCS characters issue on Vista and Windows7
6218752: Update HKSCS and GB18030 converters for Unicode 4.1

Webrev:
http://cr.openjdk.java.net/~sherman/hkscs2008/webrev/
http://cr.openjdk.java.net/~sherman/hkscs2008/test/webrev/

Background Info:
HK gov     http://www.ogcio.gov.hk/ccli/eng/hkscs/introduction.html
Microsoft  http://www.microsoft.com/hk/HKSCS/
Wiki         http://en.wikipedia.org/wiki/HKSCS

HKSCS Versions:

0. HKSCS-2008
         The HKSCS-2008 is an updated version of the Hong Kong 
Supplementary
         Character Set-2004 (HKSCS-2004) published in May 2005. It includes
         5,009 characters of which 68 are newly added. The HKSCS-2008 is 
aligned
         technically with the ISO/IEC 10646:2003 and its Amendments 1 to 6
         published in October 2009 by the International Organization for
         Standardization (ISO).
1. HKSCS-2004
         denotes the 123 characters that are newly included in the 
HKSCS-2004.
2. HKSCS-2001
         denotes the 116 characters that are newly included in the 
HKSCS-2001.
3. HKSCS-1999
         denotes characters that are included since the first version   
of the HKSCS that was released in 1999, which contains 4,702 characters.

* HKSCS-2004 and later use Unicode 4.1 code-point/mapping.

JDK currently has two versions of HKSCS charset in its charset repository.
    1. Big5_HKSCS is built on HKSCS-2001, which is used as the default 
charset for Solaris  zh_hk
       locale (there is no indication that Solaris will move on to new 
version anytime soon)
    2. MS950_HKSCS is built on a mixed HKSCS2001/1999 version
       Windows XP claims it's based on 2001 but its mapping table 
suggests actually it's a pre-2001
       version which does not use supplementary characters at all, our 
implementation matches what
       the XP has.
       Vista (and later) now "moves on" to HKSCS2004, it has native 
support (in Unicode only) for
       HKSCSC2004 in its zh_hk locale. This is where the requests of 
upgrading come from.

Solution:

(1) Support HKSCS2008 in JDK7 (instead of the requested HKSCS2004)
   The good thing about HKSCS2008 is that it only added 68 NEW 
characters into the 2004
   version, so it does not have any compatibility issue, you only get 68 
more mappings, which
   would be "unmappable" in 2004. I don't see any reason to do HKSCS2004 
when the latest
   version is out already. (HK promised this would be the "last" version 
of doing hkscs in Big5
   encoding, from now on, they will ONLY add new characters with Unicode 
code point)

   -Big5_HKSCS and MS950_HKSCS charsets are now based on HKSCS2008.
   -MS950_HKSCS is going to be the default charset for zh_HK locale on 
vista and beyond.

(2) Charset Big5_HKSCS_2001 is HKSCS-2001 based (has exactly the same 
mapping table
    as the current Big5_HKSCS, which is 2001 based implementation). This 
is  going to be the
    default "hkscs" charset for Solaris zh_HK locale (as explained 
above, Solaris  has no plan to
    upgrade for now)

(3) Charset MS950_HKSCS_XP is the mixed-2001/1999 based hkscs for 
Windows XP, this one
   has the same mapping as current MS950_HKSCS. This charset is going to 
be the default
   "hkscs" charset for Windows XP.

(4) We also have sun.io.ByteToChar/CharToByteBig5/MS950_HKSCS.
     So to make life easy,
    -removed CharToByte/ByteToCharHKSCS/HKSCS_2001
    -CharToByte/ByteToCharBig5/MS950_HKSCS now base on HKSCS2008
    (a big bonus for sun.io.c2b/b2c users :-)   )

(5) Update the b2c/c2b mapping at sun/nio/cs/mapping to correspond the 
changes in charset.

(6) Make corresponding change in font.property configuration files

 ----------------------------------------------------------------------------------------------------------- 

Belows are changes are not direct HKSCS related, but since the HKSCS 
charsets are built
on top of the Big5 charset, I included them in this change as well. 
(These changes are
at the bottom of the webrev page, I also have a separate webrev for them 
per Martin's
request, it's here http://cr.openjdk.java.net/~sherman/big5/webrev)

(7) Migratethe Big5 charset to the "new" mapping based the 
implementation (generate the
    source from the Big5.map/nr mapping table during build time)

(8) Adjusted the Big5_Solaris to use the new Big5 charset, to build the 
Big5_Solaris tables
    on top of the Big5 tables (which should make the coding faster, with 
the price of a "little"
    extra runtime memory to hold its own tables)

(9) House-clanning in make/tools/src/build/tools/charsetmapping (rename, 
move some piece around)


So now the change is about 50+ files:-)

Sherman


From Ulf.Zibis at gmx.de  Fri Feb 26 10:19:05 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 11:19:05 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B86F490.60704@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<4B86DBDC.9090703@sun.com> <4B86F490.60704@sun.com>
Message-ID: <4B87A019.30105@gmx.de>

Have you seen, that there are some chances to make String#equals little 
faster too:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6912520

-Ulf


Am 25.02.2010 23:07, schrieb Alan Bateman:
> Kelly O'Hair wrote:
>> Yup.  My eyes must be tired, I didn't see that. :^(
> Too many repositories in the air at the same time. The webrev has been 
> refreshed. Thanks Ulf.
>
>



From Ulf.Zibis at gmx.de  Fri Feb 26 10:36:05 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 11:36:05 +0100
Subject: Codereview needed for HKSCS2008 support in JDK7
In-Reply-To: <4B871171.8060809@sun.com>
References: <4B871171.8060809@sun.com>
Message-ID: <4B87A415.4040803@gmx.de>

Sounds logical.

I'm still optimizing EUC_TW charset.
I could reduce encoder memory footprint by ~30 % and enhance speed up to 
factor 2.5.

Maybe some of my researches are of interest for reengineering HKSCS:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/docs/Changes.txt?rev=953&view=markup

Last benchmarks:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/log/EUC_TWBenchmark.Dec..Enc_I32_1.log?rev=953&view=markup
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/log/EUC_TWBenchmark.Dec..Enc_I32_2.log?rev=953&view=markup
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/log/EUC_TWBenchmark.Dec..Enc_I32_3.log?rev=953&view=markup

The sources:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/sun/nio/cs/ext

-Ulf


Am 26.02.2010 01:10, schrieb Xueming Shen:
> Alan, Martin, Masayoshi and anyone interested, please help comment and 
> review.
>
> Bugs/RFEs:
> 6911753: NSN wants to add Big5 HKSCS-2004 support
> 6902790: Converting/displaying HKSCS characters issue on Vista and 
> Windows7
> 6218752: Update HKSCS and GB18030 converters for Unicode 4.1
>
> Webrev:
> http://cr.openjdk.java.net/~sherman/hkscs2008/webrev/
> http://cr.openjdk.java.net/~sherman/hkscs2008/test/webrev/
>
> Background Info:
> HK gov     http://www.ogcio.gov.hk/ccli/eng/hkscs/introduction.html
> Microsoft  http://www.microsoft.com/hk/HKSCS/
> Wiki         http://en.wikipedia.org/wiki/HKSCS
>
>



From dmitry.nadezhin at gmail.com  Fri Feb 26 11:52:26 2010
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Fri, 26 Feb 2010 14:52:26 +0300
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 
	6815768 (String.hashCode)
In-Reply-To: <4B87A019.30105@gmx.de>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<4B86DBDC.9090703@sun.com> <4B86F490.60704@sun.com>
	<4B87A019.30105@gmx.de>
Message-ID: <5a8e758b1002260352y4cc21efdo18615f0da9e385aa@mail.gmail.com>

I found two alternatives in the link
http://mail.openjdk.java.net/pipermail/coin-dev/2009-December/002618.html

The first alternative

int equalByHashThreshold = 2;

public boolean equals(Object anObject) {
  if (this == anObject) {
    return true;
  }
  if (anObject instanceof String) {

    String anotherString = (String)anObject;
    int n = count;
    if (n == anotherString.count &&
        (equalByHashThreshold == 0 || --equalByHashThreshold == 0) &&
        (anotherString.equalByHashThreshold == 0 ||
--anotherString.equalByHashThreshold == 0) &&

        hash() == anotherString.hash()) {
[snipped]
    }
  }
  return false;
}


will say that
"A".equals("A") == false
because body of if statement will not be executed

The second alternative

public int hashCode() {
  int h = hash;
  if (h == 0 || --h == 0) {
    int off = offset;
    char val[] = value;
    int len = count;


    for (int i = 0; i < len; i++) {
      h = 31*h + val[off++];
    }
    hash = h;
  }
  return h;
}

will return sequentially

"A".hashCode() == 65
"A".hashCode() == 64
"A".hashCode() == 64
. . .

I guess that you mean something else.

  -Dima

On Fri, Feb 26, 2010 at 1:19 PM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Have you seen, that there are some chances to make String#equals little
> faster too:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6912520
>
> -Ulf
>
>
> Am 25.02.2010 23:07, schrieb Alan Bateman:
>
>> Kelly O'Hair wrote:
>>
>>> Yup.  My eyes must be tired, I didn't see that. :^(
>>>
>> Too many repositories in the air at the same time. The webrev has been
>> refreshed. Thanks Ulf.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100226/c83bbc7a/attachment.html>

From Alan.Bateman at Sun.COM  Fri Feb 26 12:58:11 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 26 Feb 2010 12:58:11 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <SNT114-W1F6BA90892B5059181C1183400@phx.gbl>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>
Message-ID: <4B87C563.5070609@sun.com>

Jason Mehrens wrote:
> Alan,
>  
> Shouldn't the loading of 'this.count' into 'len' be only performed if 
> 'h' is zero?  Otherwise, when hash is not zero we perform a little 
> unnecessary work every time hashCode is called.
>  
> Jason
That's a good suggestion although it might be hard to measure any 
difference.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100226/e1d0483d/attachment.html>

From Alan.Bateman at Sun.COM  Fri Feb 26 13:00:02 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 26 Feb 2010 13:00:02 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B87A019.30105@gmx.de>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<4B86DBDC.9090703@sun.com> <4B86F490.60704@sun.com>
	<4B87A019.30105@gmx.de>
Message-ID: <4B87C5D2.8030004@sun.com>

Ulf Zibis wrote:
> Have you seen, that there are some chances to make String#equals 
> little faster too:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6912520
>
> -Ulf
Yes, I have seen it, but for now anyway, I'm not actually doing any work 
on String but rather just bringing forward fixes that we didn't have in 
OpenJDK.

-Alan.


From Ulf.Zibis at gmx.de  Fri Feb 26 15:19:37 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 16:19:37 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and 	6815768 (String.hashCode)
In-Reply-To: <5a8e758b1002260352y4cc21efdo18615f0da9e385aa@mail.gmail.com>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>	<4B86DBDC.9090703@sun.com>
	<4B86F490.60704@sun.com>	<4B87A019.30105@gmx.de>
	<5a8e758b1002260352y4cc21efdo18615f0da9e385aa@mail.gmail.com>
Message-ID: <4B87E689.50608@gmx.de>

Am 26.02.2010 12:52, schrieb Dmitry Nadezhin:
> I found two alternatives in the link
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-December/002618.html
>    
> The first alternative
> int equalByHashThreshold = 2;
>
> public boolean equals(Object anObject) {
>    if (this == anObject) {
>      return true;
>    }
>    if (anObject instanceof String) {
>
>      String anotherString = (String)anObject;
>      int n = count;
>      if (n == anotherString.count&&
>          (equalByHashThreshold == 0 || --equalByHashThreshold == 0)&&
>          (anotherString.equalByHashThreshold == 0 || --anotherString.equalByHashThreshold == 0)&&
>
>
>          hash() == anotherString.hash()) {
> [snipped]
>      }
>    }
>    return false;
> }
>    
>
> will say that
> "A".equals("A") == false
> because body of if statement will not be executed

I don't understand your problem.
1. String literals are always interned, so "A" is always identical to 
"A". Therefore the body of the 1st if will return true.
2. If the strings are not identical, body of 2nd if will be executed, if 
anObject is instance of String.

>
> The second alternative
> public int hashCode() {
>    int h = hash;
>    if (h == 0 || --h == 0) {
>      int off = offset;
>      char val[] = value;
>      int len = count;
>
>
>
>      for (int i = 0; i<  len; i++) {
>        h = 31*h + val[off++];
>      }
>      hash = h;
>    }
>    return h;
> }
>    
> will return sequentially
>
> "A".hashCode() == 65
> "A".hashCode() == 64
> "A".hashCode() == 64
> . . .

You are right. Good catch.

So better:

public int hashCode() {
   int h = hash;
   if (h == 0) {
     int len = count;
     if (len>  0) {
       char[] val = value;
       for (int i = 0, off = offset; i<  len; i++)
         h = 31*h + val[off++];
       hash = h;
     }
   } else if (h == 1) {
     hash = 0;
     return hashCode();
   }
   return h;
}


- Ulf




From Ulf.Zibis at gmx.de  Fri Feb 26 15:25:24 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 16:25:24 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B87C563.5070609@sun.com>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>
	<4B87C563.5070609@sun.com>
Message-ID: <4B87E7E4.7030202@gmx.de>

Am 26.02.2010 13:58, schrieb Alan Bateman:
> Jason Mehrens wrote:
>> Alan,
>>
>> Shouldn't the loading of 'this.count' into 'len' be only performed if 
>> 'h' is zero?  Otherwise, when hash is not zero we perform a little 
>> unnecessary work every time hashCode is called.
>>
>> Jason
> That's a good suggestion although it might be hard to measure any 
> difference.
>

In case of HotSpot compiled code, I guess, len will not be filled by 
this.count before it is actually needed, but in interpreted code Jason 
may be right.

So optimum could be:

public int hashCode() {
   int h = hash;
   if (h == 0) {
     int len = count;
     if (len>  0) {
       char[] val = value;
       for (int i = 0, off = offset; i<  len; i++)
         h = 31*h + val[off++];
       hash = h;
     }
   }
   return h;
}


- Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100226/9973f7d0/attachment.html>

From dmitry.nadezhin at gmail.com  Fri Feb 26 15:27:32 2010
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Fri, 26 Feb 2010 18:27:32 +0300
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 
	6815768 (String.hashCode)
In-Reply-To: <4B87E689.50608@gmx.de>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<4B86DBDC.9090703@sun.com> <4B86F490.60704@sun.com>
	<4B87A019.30105@gmx.de>
	<5a8e758b1002260352y4cc21efdo18615f0da9e385aa@mail.gmail.com>
	<4B87E689.50608@gmx.de>
Message-ID: <5a8e758b1002260727s50255830sa66c6cde29117e16@mail.gmail.com>

On Fri, Feb 26, 2010 at 6:19 PM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 26.02.2010 12:52, schrieb Dmitry Nadezhin:
>
>  I found two alternatives in the link
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-December/002618.html
>>   The first alternative
>> int equalByHashThreshold = 2;
>>
>> public boolean equals(Object anObject) {
>>   if (this == anObject) {
>>     return true;
>>   }
>>   if (anObject instanceof String) {
>>
>>     String anotherString = (String)anObject;
>>     int n = count;
>>     if (n == anotherString.count&&
>>         (equalByHashThreshold == 0 || --equalByHashThreshold == 0)&&
>>         (anotherString.equalByHashThreshold == 0 ||
>> --anotherString.equalByHashThreshold == 0)&&
>>
>>
>>         hash() == anotherString.hash()) {
>> [snipped]
>>     }
>>   }
>>   return false;
>> }
>>
>> will say that
>> "A".equals("A") == false
>> because body of if statement will not be executed
>>
>
> I don't understand your problem.
> 1. String literals are always interned, so "A" is always identical to "A".
> Therefore the body of the 1st if will return true.
> 2. If the strings are not identical, body of 2nd if will be executed, if
> anObject is instance of String.
>

I'm sorry. The example should be
new String("A").equals("A") == false .
In this case Strings are not identical. The first if wil not return.
The second if will be executed.
The third if will not be executed because
(equalByHashThreshold == 0 || --equalByHashThreshhold == 0)  <=> (2 == 0 ||
1 == 0) <=> false .

  -Dima
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100226/0ef2971e/attachment.html>

From Ulf.Zibis at gmx.de  Fri Feb 26 16:10:13 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 17:10:13 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B87E7E4.7030202@gmx.de>
References: <4B86B8A4.8050709@sun.com>	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>	<4B86DAE1.5050208@gmx.de>	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>	<4B87C563.5070609@sun.com>
	<4B87E7E4.7030202@gmx.de>
Message-ID: <4B87F265.4010307@gmx.de>

Am 26.02.2010 16:25, schrieb Ulf Zibis:
> So optimum could be:
>

I have one more ...
Additionally we can save double incrementing of int i and off:

public int hashCode() {
   int h = hash;
   if (h == 0) {
     int len = count;
     if (len>  0) {
       char[] val = value;
//      for (int i = offset, len += i; i<  len; ) // would be nice syntax ->  RFE to project coin
       for (int i = offset, limit = len += i; i<  len; i++)
         h = 31*h + val[i];
       hash = h;
     }
   }
   return h;
}


- Ulf





From Ulf.Zibis at gmx.de  Fri Feb 26 16:13:07 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 17:13:07 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B86CAC5.4050405@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com>
Message-ID: <4B87F313.7010609@gmx.de>

Additionally I think:

       char[] val = value;

looks better then:

       char val[] = value;


-Ulf



Am 25.02.2010 20:08, schrieb Alan Bateman:
> Kelly O'Hair wrote:
>> Looks fine to me.
>>
>> -kto
> Thanks Kelly and also to Joe for pointing out that I botched the link 
> to the second one - here is the right webrev:
>  http://cr.openjdk.java.net/~alanb/6921374/webrev/
>
> -Alan
>
>
>



From jonathan.gibbons at sun.com  Fri Feb 26 16:43:27 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 26 Feb 2010 16:43:27 +0000
Subject: hg: jdk7/tl/langtools: 6881645: Unchecked method call on a method
	declared inside anonymous inner causes javac to crash
Message-ID: <20100226164330.8BF3041902@hg.openjdk.java.net>

Changeset: b030706da5b4
Author:    jjg
Date:      2010-02-26 08:42 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b030706da5b4

6881645: Unchecked method call on a method declared inside anonymous inner causes javac to crash
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/T6881645.java



From Ulf.Zibis at gmx.de  Fri Feb 26 17:11:46 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 18:11:46 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B87F265.4010307@gmx.de>
References: <4B86B8A4.8050709@sun.com>	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>	<4B86DAE1.5050208@gmx.de>	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>	<4B87C563.5070609@sun.com>	<4B87E7E4.7030202@gmx.de>
	<4B87F265.4010307@gmx.de>
Message-ID: <4B8800D2.4090006@gmx.de>

Am 26.02.2010 17:10, schrieb Ulf Zibis:
> Additionally we can save double incrementing of int i and off:
>
> public int hashCode() {
>   int h = hash;
>   if (h == 0) {
>     int len = count;
>     if (len>  0) {
>       char[] val = value;
> //      for (int i = offset, len += i; i<  len; ) // would be nice 
> syntax ->  RFE to project coin
>       for (int i = offset, limit = len += i; i < len; i++)
>         h = 31*h + val[i];
>       hash = h;
>     }
>   }
>   return h;
> }
>

And in hotspot/src/share/vm/classfile/symbolTable.cpp :

int StringTable::hash_string(jchar* s, int len) {
   unsigned h = 0;
   for (len = s + len*sizeof(jchar); s < len; s++)
     h = 31*h + (unsigned) *s;
   return h;
}


-Ulf




From Alan.Bateman at Sun.COM  Fri Feb 26 19:32:32 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 26 Feb 2010 19:32:32 +0000
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and
	6815768 (String.hashCode)
In-Reply-To: <4B87F265.4010307@gmx.de>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl> <4B87C563.5070609@sun.com>
	<4B87E7E4.7030202@gmx.de> <4B87F265.4010307@gmx.de>
Message-ID: <4B8821D0.40803@sun.com>

Ulf Zibis wrote:
> Am 26.02.2010 16:25, schrieb Ulf Zibis:
>> So optimum could be:
>>
>
> I have one more ...
> Additionally we can save double incrementing of int i and off:
>
> public int hashCode() {
>   int h = hash;
>   if (h == 0) {
>     int len = count;
>     if (len>  0) {
>       char[] val = value;
> //      for (int i = offset, len += i; i<  len; ) // would be nice 
> syntax ->  RFE to project coin
>       for (int i = offset, limit = len += i; i<  len; i++)
>         h = 31*h + val[i];
>       hash = h;
>     }
>   }
>   return h;
> }
>
>
> - Ulf
>
For these other suggestions it would be great to create micro-benchmarks 
and try our your changes.

For now though, as I said, I'm just fixing the method to avoid the store 
for the empty string case.

-Alan.


From Ulf.Zibis at gmx.de  Fri Feb 26 22:51:02 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 26 Feb 2010 23:51:02 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B8821D0.40803@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>
	<4B87C563.5070609@sun.com> <4B87E7E4.7030202@gmx.de>
	<4B87F265.4010307@gmx.de> <4B8821D0.40803@sun.com>
Message-ID: <4B885056.1010903@gmx.de>

Am 26.02.2010 20:32, schrieb Alan Bateman:
> Ulf Zibis wrote:
> For these other suggestions it would be great to create 
> micro-benchmarks and try our your changes.
>
> For now though, as I said, I'm just fixing the method to avoid the 
> store for the empty string case.

I've run a benchmark for your "avoid the store for the empty string case":

a1.equals(a2)
a1.equals(a2)
hashCode() warmup =     25,469 ms
hashCode1() warmup =    116,709 ms
hashCode() time =     11,789 ms
hashCode1() time =     17,744 ms
hashCodes sum = 0

My machine (notebook): 2Ghz Intel Centrino, single core, I32 architecture.
I can't see any advantage of this code. As I guessed before, HotSpot 
server compiler seems to first examine the count value before doing 
anything.

Run main() of:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=954&view=markup

-Ulf




From Ulf.Zibis at gmx.de  Fri Feb 26 23:18:54 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 27 Feb 2010 00:18:54 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B8821D0.40803@sun.com>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>	<4B87C563.5070609@sun.com>
	<4B87E7E4.7030202@gmx.de>	<4B87F265.4010307@gmx.de>
	<4B8821D0.40803@sun.com>
Message-ID: <4B8856DE.3040908@gmx.de>

Am 26.02.2010 20:32, schrieb Alan Bateman:
> Ulf Zibis wrote:
> For these other suggestions it would be great to create
> micro-benchmarks and try our your changes.
>
> For now though, as I said, I'm just fixing the method to avoid the
> store for the empty string case.

Here the benchmark for my different approaches on non-empty strings:

hashCode() warmup =     38,227 ms
hashCode1() warmup =    323,462 ms
hashCode() time =     12,066 ms
hashCode1() time =     11,620 ms
hashCodes sum = 0
hashCode() warmup =     34,928 ms
hashCode1() warmup =     19,010 ms
hashCode2() warmup =     25,938 ms
hashCode3() warmup =     22,428 ms
hashCode4() warmup =     22,966 ms
hashCode5() warmup =     21,372 ms
hashCode() time =    418,962 ms
hashCode1() time =    306,977 ms
hashCode2() time =    296,899 ms
hashCode3() time =    363,364 ms
hashCode4() time =    286,098 ms
hashCode5() time =    269,519 ms
hashCodes sum = -1427881024

See new revision:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup

-Ulf






From jonathan.gibbons at sun.com  Fri Feb 26 23:28:02 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 26 Feb 2010 23:28:02 +0000
Subject: hg: jdk7/tl/langtools: 6930076: "null" can incorrectly appear in
	error message compiler.err.error.reading.file
Message-ID: <20100226232805.0F9D641976@hg.openjdk.java.net>

Changeset: 72833a8a6086
Author:    jjg
Date:      2010-02-26 15:26 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/72833a8a6086

6930076: "null" can incorrectly appear in error message compiler.err.error.reading.file
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/Paths.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java



From jonathan.gibbons at sun.com  Fri Feb 26 23:31:24 2010
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 26 Feb 2010 23:31:24 +0000
Subject: hg: jdk7/tl/langtools: 6930032: fix findbugs errors in
	com.sun.tools.javac.comp
Message-ID: <20100226233127.44DF241978@hg.openjdk.java.net>

Changeset: 7b69c7083a97
Author:    jjg
Date:      2010-02-26 15:30 -0800
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7b69c7083a97

6930032: fix findbugs errors in com.sun.tools.javac.comp
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java



From dmitry.nadezhin at gmail.com  Sat Feb 27 14:00:14 2010
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 27 Feb 2010 17:00:14 +0300
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 
	6815768 (String.hashCode)
In-Reply-To: <4B8856DE.3040908@gmx.de>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>
	<4B87C563.5070609@sun.com> <4B87E7E4.7030202@gmx.de>
	<4B87F265.4010307@gmx.de> <4B8821D0.40803@sun.com>
	<4B8856DE.3040908@gmx.de>
Message-ID: <5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>

Ulf,

I ran Caliper benchmarks on different variants of hashCode().
http://code.google.com/p/caliper/
The results and the Caliper code are below:

  -Dima

--------- -d32 -clien
 0% Scenario{vm=java -d32 -client, benchmark=HashCodeEmpty} 8,85ns; ?=0,06ns
@ 3 trials
 8% Scenario{vm=java -d32 -client, benchmark=HashCode1Empty} 7,20ns;
?=0,04ns @ 3 trials
17% Scenario{vm=java -d32 -client, benchmark=HashCode2Empty} 7,79ns;
?=0,32ns @ 10 trials
25% Scenario{vm=java -d32 -client, benchmark=HashCode3Empty} 7,88ns;
?=0,31ns @ 10 trials
33% Scenario{vm=java -d32 -client, benchmark=HashCode4Empty} 7,92ns;
?=0,31ns @ 10 trials
42% Scenario{vm=java -d32 -client, benchmark=HashCode5Empty} 7,06ns;
?=0,27ns @ 10 trials
50% Scenario{vm=java -d32 -client, benchmark=HashCodeLong} 145,22ns;
?=0,68ns @ 3 trials
58% Scenario{vm=java -d32 -client, benchmark=HashCode1Long} 144,58ns;
?=0,55ns @ 3 trials
67% Scenario{vm=java -d32 -client, benchmark=HashCode2Long} 167,55ns;
?=1,58ns @ 6 trials
75% Scenario{vm=java -d32 -client, benchmark=HashCode3Long} 122,87ns;
?=0,34ns @ 3 trials
83% Scenario{vm=java -d32 -client, benchmark=HashCode4Long} 122,69ns;
?=0,36ns @ 3 trials
92% Scenario{vm=java -d32 -client, benchmark=HashCode5Long} 126,11ns;
?=0,77ns @ 3 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    9 X|||||||||||
HashCode1Empty    7 X||||||||||
HashCode2Empty    8 X|||||||||||
HashCode3Empty    8 X|||||||||||
HashCode4Empty    8 X|||||||||||
HashCode5Empty    7 X||||||||||
  HashCodeLong  145 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode1Long  145 XXXXXXXXXXXXXXXXXXXXXXXXX||||
 HashCode2Long  168 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 HashCode3Long  123 XXXXXXXXXXXXXXXXXXXXXX||||||
 HashCode4Long  123 XXXXXXXXXXXXXXXXXXXXX|||||||
 HashCode5Long  126 XXXXXXXXXXXXXXXXXXXXXX||||||

vm: java -d32 -client
--------
-------- -d32 -server
 0% Scenario{vm=java -d32 -server, benchmark=HashCodeEmpty} 1,69ns; ?=0,01ns
@ 3 trials
 8% Scenario{vm=java -d32 -server, benchmark=HashCode1Empty} 2,00ns;
?=0,07ns @ 10 trials
17% Scenario{vm=java -d32 -server, benchmark=HashCode2Empty} 1,97ns;
?=0,01ns @ 3 trials
25% Scenario{vm=java -d32 -server, benchmark=HashCode3Empty} 1,55ns;
?=0,01ns @ 3 trials
33% Scenario{vm=java -d32 -server, benchmark=HashCode4Empty} 1,54ns;
?=0,01ns @ 3 trials
42% Scenario{vm=java -d32 -server, benchmark=HashCode5Empty} 2,32ns;
?=0,01ns @ 3 trials
50% Scenario{vm=java -d32 -server, benchmark=HashCodeLong} 113,01ns;
?=5,69ns @ 10 trials
58% Scenario{vm=java -d32 -server, benchmark=HashCode1Long} 101,49ns;
?=0,89ns @ 3 trials
67% Scenario{vm=java -d32 -server, benchmark=HashCode2Long} 102,93ns;
?=0,26ns @ 3 trials
75% Scenario{vm=java -d32 -server, benchmark=HashCode3Long} 100,29ns;
?=0,98ns @ 3 trials
83% Scenario{vm=java -d32 -server, benchmark=HashCode4Long} 100,00ns;
?=0,94ns @ 5 trials
92% Scenario{vm=java -d32 -server, benchmark=HashCode5Long} 112,29ns;
?=1,22ns @ 10 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    2 |||
HashCode1Empty    2 ||||
HashCode2Empty    2 ||||
HashCode3Empty    2 ||
HashCode4Empty    2 ||
HashCode5Empty    2 |||||
  HashCodeLong  113 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 HashCode1Long  101 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode2Long  103 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode3Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode4Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode5Long  112 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vm: java -d32 -server
------
------ -d64 -client
 0% Scenario{vm=java -d64 -client, benchmark=HashCodeEmpty} 1,63ns; ?=0,01ns
@ 3 trials
 8% Scenario{vm=java -d64 -client, benchmark=HashCode1Empty} 1,41ns;
?=0,01ns @ 3 trials
17% Scenario{vm=java -d64 -client, benchmark=HashCode2Empty} 1,40ns;
?=0,01ns @ 3 trials
25% Scenario{vm=java -d64 -client, benchmark=HashCode3Empty} 1,42ns;
?=0,01ns @ 3 trials
33% Scenario{vm=java -d64 -client, benchmark=HashCode4Empty} 1,40ns;
?=0,00ns @ 3 trials
42% Scenario{vm=java -d64 -client, benchmark=HashCode5Empty} 4,29ns;
?=0,11ns @ 10 trials
50% Scenario{vm=java -d64 -client, benchmark=HashCodeLong} 101,74ns;
?=0,12ns @ 3 trials
58% Scenario{vm=java -d64 -client, benchmark=HashCode1Long} 102,66ns;
?=0,91ns @ 3 trials
67% Scenario{vm=java -d64 -client, benchmark=HashCode2Long} 100,41ns;
?=0,45ns @ 3 trials
75% Scenario{vm=java -d64 -client, benchmark=HashCode3Long} 97,41ns;
?=0,57ns @ 3 trials
83% Scenario{vm=java -d64 -client, benchmark=HashCode4Long} 97,92ns;
?=0,46ns @ 3 trials
92% Scenario{vm=java -d64 -client, benchmark=HashCode5Long} 107,27ns;
?=0,97ns @ 3 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    2 |||
HashCode1Empty    1 ||
HashCode2Empty    1 ||
HashCode3Empty    1 ||
HashCode4Empty    1 ||
HashCode5Empty    4 X||||||||
  HashCodeLong  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode1Long  103 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode2Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode3Long   97 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode4Long   98 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode5Long  107 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vm: java -d64 -client
-------
------ -d64 -server
 0% Scenario{vm=java -d64 -server, benchmark=HashCodeEmpty} 1,62ns; ?=0,00ns
@ 3 trials
 8% Scenario{vm=java -d64 -server, benchmark=HashCode1Empty} 1,42ns;
?=0,00ns @ 3 trials
17% Scenario{vm=java -d64 -server, benchmark=HashCode2Empty} 1,42ns;
?=0,01ns @ 3 trials
25% Scenario{vm=java -d64 -server, benchmark=HashCode3Empty} 1,42ns;
?=0,00ns @ 3 trials
33% Scenario{vm=java -d64 -server, benchmark=HashCode4Empty} 1,41ns;
?=0,01ns @ 3 trials
42% Scenario{vm=java -d64 -server, benchmark=HashCode5Empty} 4,20ns;
?=0,03ns @ 3 trials
50% Scenario{vm=java -d64 -server, benchmark=HashCodeLong} 102,05ns;
?=0,22ns @ 3 trials
58% Scenario{vm=java -d64 -server, benchmark=HashCode1Long} 102,33ns;
?=0,62ns @ 3 trials
67% Scenario{vm=java -d64 -server, benchmark=HashCode2Long} 100,70ns;
?=0,43ns @ 3 trials
75% Scenario{vm=java -d64 -server, benchmark=HashCode3Long} 96,92ns;
?=0,90ns @ 3 trials
83% Scenario{vm=java -d64 -server, benchmark=HashCode4Long} 98,22ns;
?=0,40ns @ 3 trials
92% Scenario{vm=java -d64 -server, benchmark=HashCode5Long} 108,22ns;
?=1,45ns @ 10 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    2 |||
HashCode1Empty    1 ||
HashCode2Empty    1 ||
HashCode3Empty    1 ||
HashCode4Empty    1 ||
HashCode5Empty    4 X||||||||
  HashCodeLong  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode1Long  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode2Long  101 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode3Long   97 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode4Long   98 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode5Long  108 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vm: java -d64 -server
-------------
------------- StringHashCodeBenchmark.java
package examples;

import com.google.caliper.SimpleBenchmark;
import java_lang.String;

public class StringHashCodeBenchmark extends SimpleBenchmark {

    private String EMPTY = new String("");
    private String LONG = new
String("@ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ");

    public int timeHashCodeEmpty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode();
        }
        return dummy;
    }

    public int timeHashCode1Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode1();
        }
        return dummy;
    }

    public int timeHashCode2Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode2();
        }
        return dummy;
    }

    public int timeHashCode3Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode3();
        }
        return dummy;
    }

    public int timeHashCode4Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode4();
        }
        return dummy;
    }

    public int timeHashCode5Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode5();
        }
        return dummy;
    }

    public int timeHashCodeLong(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode();
        }
        return dummy;
    }

    public int timeHashCode1Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode1();
        }
        return dummy;
    }

    public int timeHashCode2Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode2();
        }
        return dummy;
    }

    public int timeHashCode3Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode3();
        }
        return dummy;
    }

    public int timeHashCode4Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode4();
        }
        return dummy;
    }

    public int timeHashCode5Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode5();
        }
        return dummy;
    }
}
----------------

On Sat, Feb 27, 2010 at 2:18 AM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 26.02.2010 20:32, schrieb Alan Bateman:
>
>> Ulf Zibis wrote:
>> For these other suggestions it would be great to create
>> micro-benchmarks and try our your changes.
>>
>> For now though, as I said, I'm just fixing the method to avoid the
>> store for the empty string case.
>>
>
> Here the benchmark for my different approaches on non-empty strings:
>
> hashCode() warmup =     38,227 ms
> hashCode1() warmup =    323,462 ms
> hashCode() time =     12,066 ms
> hashCode1() time =     11,620 ms
> hashCodes sum = 0
> hashCode() warmup =     34,928 ms
> hashCode1() warmup =     19,010 ms
> hashCode2() warmup =     25,938 ms
> hashCode3() warmup =     22,428 ms
> hashCode4() warmup =     22,966 ms
> hashCode5() warmup =     21,372 ms
> hashCode() time =    418,962 ms
> hashCode1() time =    306,977 ms
> hashCode2() time =    296,899 ms
> hashCode3() time =    363,364 ms
> hashCode4() time =    286,098 ms
> hashCode5() time =    269,519 ms
> hashCodes sum = -1427881024
>
> See new revision:
>
> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup
>
> -Ulf
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100227/995d4d1b/attachment.html>

From Ulf.Zibis at gmx.de  Sat Feb 27 15:12:24 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 27 Feb 2010 16:12:24 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and 	6815768 (String.hashCode)
In-Reply-To: <5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>	<4B87C563.5070609@sun.com>
	<4B87E7E4.7030202@gmx.de>	<4B87F265.4010307@gmx.de>
	<4B8821D0.40803@sun.com>	<4B8856DE.3040908@gmx.de>
	<5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>
Message-ID: <4B893658.3000901@gmx.de>

Dmitry,

thanks for the interesting results.

Your results are not as promising as mine.
I guess, referring to the HotSpot's dissassembler dump would give more 
hints.
Additionally different string lengths, repeat factors, -Xbatch, and GC 
settings would help.

Good trick to use substring(1) for cheap instatiation.

To estimate the instantiation cost you could add:
     public int timeInitLong(int reps) {
         int dummy = 0;
         for (int i = 0; i < reps; i++) {
             dummy += LONG.substring(1).offset - 1;
         }
         return dummy;
     }

Do you have any idea, why first hashCode1() warmup is 10 times slower 
than hashCode() warmup in my case?

-Ulf


Am 27.02.2010 15:00, schrieb Dmitry Nadezhin:
> Ulf,
>
> I ran Caliper benchmarks on different variants of hashCode().
> http://code.google.com/p/caliper/
> The results and the Caliper code are below:
>
>   -Dima
>
>
> On Sat, Feb 27, 2010 at 2:18 AM, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Am 26.02.2010 20:32, schrieb Alan Bateman:
>
>         Ulf Zibis wrote:
>         For these other suggestions it would be great to create
>         micro-benchmarks and try our your changes.
>
>         For now though, as I said, I'm just fixing the method to avoid the
>         store for the empty string case.
>
>
>     Here the benchmark for my different approaches on non-empty strings:
>
>     hashCode() warmup =     38,227 ms
>     hashCode1() warmup =    323,462 ms
>     hashCode() time =     12,066 ms
>     hashCode1() time =     11,620 ms
>     hashCodes sum = 0
>     hashCode() warmup =     34,928 ms
>     hashCode1() warmup =     19,010 ms
>     hashCode2() warmup =     25,938 ms
>     hashCode3() warmup =     22,428 ms
>     hashCode4() warmup =     22,966 ms
>     hashCode5() warmup =     21,372 ms
>     hashCode() time =    418,962 ms
>     hashCode1() time =    306,977 ms
>     hashCode2() time =    296,899 ms
>     hashCode3() time =    363,364 ms
>     hashCode4() time =    286,098 ms
>     hashCode5() time =    269,519 ms
>     hashCodes sum = -1427881024
>
>     See new revision:
>     https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup
>     <https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup>
>
>     -Ulf
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100227/4e565752/attachment.html>

From jason_mehrens at hotmail.com  Sat Feb 27 17:50:46 2010
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Sat, 27 Feb 2010 11:50:46 -0600
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and 	6815768 (String.hashCode)
In-Reply-To: <5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>,<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>, <SNT114-W1F6BA90892B5059181C1183400@phx.gbl>,
	<4B87C563.5070609@sun.com>
	<4B87E7E4.7030202@gmx.de>,<4B87F265.4010307@gmx.de>
	<4B8821D0.40803@sun.com>, <4B8856DE.3040908@gmx.de>,
	<5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>
Message-ID: <SNT114-W16D4D0A7D28AD7F6A6EC56833E0@phx.gbl>


Here are two more variants you might want to throw into the benchmark.

 

  public int hashCode6() {
        int h = hash;
        if (h == 0 && count > 0) {
            int off = offset;
            char val[] = value;
            int len = count;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
  }

 

  public int hashCode7() {
        int h = hash;

        int len;
        if (h == 0 && (len = count) > 0) {
            int off = offset;
            char val[] = value;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
  }

 

Jason

 


Date: Sat, 27 Feb 2010 17:00:14 +0300
Subject: Re: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)
From: dmitry.nadezhin at gmail.com
To: core-libs-dev at openjdk.java.net

Ulf,

I ran Caliper benchmarks on different variants of hashCode().
http://code.google.com/p/caliper/
The results and the Caliper code are below:

  -Dima

--------- -d32 -clien
 0% Scenario{vm=java -d32 -client, benchmark=HashCodeEmpty} 8,85ns; ?=0,06ns @ 3 trials
 8% Scenario{vm=java -d32 -client, benchmark=HashCode1Empty} 7,20ns; ?=0,04ns @ 3 trials
17% Scenario{vm=java -d32 -client, benchmark=HashCode2Empty} 7,79ns; ?=0,32ns @ 10 trials
25% Scenario{vm=java -d32 -client, benchmark=HashCode3Empty} 7,88ns; ?=0,31ns @ 10 trials
33% Scenario{vm=java -d32 -client, benchmark=HashCode4Empty} 7,92ns; ?=0,31ns @ 10 trials
42% Scenario{vm=java -d32 -client, benchmark=HashCode5Empty} 7,06ns; ?=0,27ns @ 10 trials
50% Scenario{vm=java -d32 -client, benchmark=HashCodeLong} 145,22ns; ?=0,68ns @ 3 trials
58% Scenario{vm=java -d32 -client, benchmark=HashCode1Long} 144,58ns; ?=0,55ns @ 3 trials
67% Scenario{vm=java -d32 -client, benchmark=HashCode2Long} 167,55ns; ?=1,58ns @ 6 trials
75% Scenario{vm=java -d32 -client, benchmark=HashCode3Long} 122,87ns; ?=0,34ns @ 3 trials
83% Scenario{vm=java -d32 -client, benchmark=HashCode4Long} 122,69ns; ?=0,36ns @ 3 trials
92% Scenario{vm=java -d32 -client, benchmark=HashCode5Long} 126,11ns; ?=0,77ns @ 3 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    9 X|||||||||||
HashCode1Empty    7 X||||||||||
HashCode2Empty    8 X|||||||||||
HashCode3Empty    8 X|||||||||||
HashCode4Empty    8 X|||||||||||
HashCode5Empty    7 X||||||||||
  HashCodeLong  145 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode1Long  145 XXXXXXXXXXXXXXXXXXXXXXXXX||||
 HashCode2Long  168 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 HashCode3Long  123 XXXXXXXXXXXXXXXXXXXXXX||||||
 HashCode4Long  123 XXXXXXXXXXXXXXXXXXXXX|||||||
 HashCode5Long  126 XXXXXXXXXXXXXXXXXXXXXX||||||

vm: java -d32 -client
--------
-------- -d32 -server
 0% Scenario{vm=java -d32 -server, benchmark=HashCodeEmpty} 1,69ns; ?=0,01ns @ 3 trials
 8% Scenario{vm=java -d32 -server, benchmark=HashCode1Empty} 2,00ns; ?=0,07ns @ 10 trials
17% Scenario{vm=java -d32 -server, benchmark=HashCode2Empty} 1,97ns; ?=0,01ns @ 3 trials
25% Scenario{vm=java -d32 -server, benchmark=HashCode3Empty} 1,55ns; ?=0,01ns @ 3 trials
33% Scenario{vm=java -d32 -server, benchmark=HashCode4Empty} 1,54ns; ?=0,01ns @ 3 trials
42% Scenario{vm=java -d32 -server, benchmark=HashCode5Empty} 2,32ns; ?=0,01ns @ 3 trials
50% Scenario{vm=java -d32 -server, benchmark=HashCodeLong} 113,01ns; ?=5,69ns @ 10 trials
58% Scenario{vm=java -d32 -server, benchmark=HashCode1Long} 101,49ns; ?=0,89ns @ 3 trials
67% Scenario{vm=java -d32 -server, benchmark=HashCode2Long} 102,93ns; ?=0,26ns @ 3 trials
75% Scenario{vm=java -d32 -server, benchmark=HashCode3Long} 100,29ns; ?=0,98ns @ 3 trials
83% Scenario{vm=java -d32 -server, benchmark=HashCode4Long} 100,00ns; ?=0,94ns @ 5 trials
92% Scenario{vm=java -d32 -server, benchmark=HashCode5Long} 112,29ns; ?=1,22ns @ 10 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    2 |||
HashCode1Empty    2 ||||
HashCode2Empty    2 ||||
HashCode3Empty    2 ||
HashCode4Empty    2 ||
HashCode5Empty    2 |||||
  HashCodeLong  113 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 HashCode1Long  101 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode2Long  103 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode3Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode4Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode5Long  112 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vm: java -d32 -server
------
------ -d64 -client
 0% Scenario{vm=java -d64 -client, benchmark=HashCodeEmpty} 1,63ns; ?=0,01ns @ 3 trials
 8% Scenario{vm=java -d64 -client, benchmark=HashCode1Empty} 1,41ns; ?=0,01ns @ 3 trials
17% Scenario{vm=java -d64 -client, benchmark=HashCode2Empty} 1,40ns; ?=0,01ns @ 3 trials
25% Scenario{vm=java -d64 -client, benchmark=HashCode3Empty} 1,42ns; ?=0,01ns @ 3 trials
33% Scenario{vm=java -d64 -client, benchmark=HashCode4Empty} 1,40ns; ?=0,00ns @ 3 trials
42% Scenario{vm=java -d64 -client, benchmark=HashCode5Empty} 4,29ns; ?=0,11ns @ 10 trials
50% Scenario{vm=java -d64 -client, benchmark=HashCodeLong} 101,74ns; ?=0,12ns @ 3 trials
58% Scenario{vm=java -d64 -client, benchmark=HashCode1Long} 102,66ns; ?=0,91ns @ 3 trials
67% Scenario{vm=java -d64 -client, benchmark=HashCode2Long} 100,41ns; ?=0,45ns @ 3 trials
75% Scenario{vm=java -d64 -client, benchmark=HashCode3Long} 97,41ns; ?=0,57ns @ 3 trials
83% Scenario{vm=java -d64 -client, benchmark=HashCode4Long} 97,92ns; ?=0,46ns @ 3 trials
92% Scenario{vm=java -d64 -client, benchmark=HashCode5Long} 107,27ns; ?=0,97ns @ 3 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    2 |||
HashCode1Empty    1 ||
HashCode2Empty    1 ||
HashCode3Empty    1 ||
HashCode4Empty    1 ||
HashCode5Empty    4 X||||||||
  HashCodeLong  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode1Long  103 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode2Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode3Long   97 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode4Long   98 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode5Long  107 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vm: java -d64 -client
-------
------ -d64 -server
 0% Scenario{vm=java -d64 -server, benchmark=HashCodeEmpty} 1,62ns; ?=0,00ns @ 3 trials
 8% Scenario{vm=java -d64 -server, benchmark=HashCode1Empty} 1,42ns; ?=0,00ns @ 3 trials
17% Scenario{vm=java -d64 -server, benchmark=HashCode2Empty} 1,42ns; ?=0,01ns @ 3 trials
25% Scenario{vm=java -d64 -server, benchmark=HashCode3Empty} 1,42ns; ?=0,00ns @ 3 trials
33% Scenario{vm=java -d64 -server, benchmark=HashCode4Empty} 1,41ns; ?=0,01ns @ 3 trials
42% Scenario{vm=java -d64 -server, benchmark=HashCode5Empty} 4,20ns; ?=0,03ns @ 3 trials
50% Scenario{vm=java -d64 -server, benchmark=HashCodeLong} 102,05ns; ?=0,22ns @ 3 trials
58% Scenario{vm=java -d64 -server, benchmark=HashCode1Long} 102,33ns; ?=0,62ns @ 3 trials
67% Scenario{vm=java -d64 -server, benchmark=HashCode2Long} 100,70ns; ?=0,43ns @ 3 trials
75% Scenario{vm=java -d64 -server, benchmark=HashCode3Long} 96,92ns; ?=0,90ns @ 3 trials
83% Scenario{vm=java -d64 -server, benchmark=HashCode4Long} 98,22ns; ?=0,40ns @ 3 trials
92% Scenario{vm=java -d64 -server, benchmark=HashCode5Long} 108,22ns; ?=1,45ns @ 10 trials

     benchmark   ns logarithmic runtime
 HashCodeEmpty    2 |||
HashCode1Empty    1 ||
HashCode2Empty    1 ||
HashCode3Empty    1 ||
HashCode4Empty    1 ||
HashCode5Empty    4 X||||||||
  HashCodeLong  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode1Long  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
 HashCode2Long  101 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode3Long   97 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
 HashCode4Long   98 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
 HashCode5Long  108 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

vm: java -d64 -server
-------------
------------- StringHashCodeBenchmark.java
package examples;

import com.google.caliper.SimpleBenchmark;
import java_lang.String;

public class StringHashCodeBenchmark extends SimpleBenchmark {

    private String EMPTY = new String("");
    private String LONG = new String("@ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ");

    public int timeHashCodeEmpty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode();
        }
        return dummy;
    }

    public int timeHashCode1Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode1();
        }
        return dummy;
    }

    public int timeHashCode2Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode2();
        }
        return dummy;
    }

    public int timeHashCode3Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode3();
        }
        return dummy;
    }

    public int timeHashCode4Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode4();
        }
        return dummy;
    }

    public int timeHashCode5Empty(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += EMPTY.hashCode5();
        }
        return dummy;
    }

    public int timeHashCodeLong(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode();
        }
        return dummy;
    }

    public int timeHashCode1Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode1();
        }
        return dummy;
    }

    public int timeHashCode2Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode2();
        }
        return dummy;
    }

    public int timeHashCode3Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode3();
        }
        return dummy;
    }

    public int timeHashCode4Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode4();
        }
        return dummy;
    }

    public int timeHashCode5Long(int reps) {
        int dummy = 0;
        for (int i = 0; i < reps; i++) {
            dummy += LONG.substring(1).hashCode5();
        }
        return dummy;
    }
}
----------------


On Sat, Feb 27, 2010 at 2:18 AM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:


Am 26.02.2010 20:32, schrieb Alan Bateman:


Ulf Zibis wrote:
For these other suggestions it would be great to create
micro-benchmarks and try our your changes.

For now though, as I said, I'm just fixing the method to avoid the
store for the empty string case.

Here the benchmark for my different approaches on non-empty strings:

hashCode() warmup =     38,227 ms
hashCode1() warmup =    323,462 ms
hashCode() time =     12,066 ms
hashCode1() time =     11,620 ms
hashCodes sum = 0
hashCode() warmup =     34,928 ms
hashCode1() warmup =     19,010 ms
hashCode2() warmup =     25,938 ms
hashCode3() warmup =     22,428 ms
hashCode4() warmup =     22,966 ms
hashCode5() warmup =     21,372 ms
hashCode() time =    418,962 ms
hashCode1() time =    306,977 ms
hashCode2() time =    296,899 ms
hashCode3() time =    363,364 ms
hashCode4() time =    286,098 ms
hashCode5() time =    269,519 ms
hashCodes sum = -1427881024

See new revision:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup

-Ulf





 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100227/dcc60861/attachment.html>

From Ulf.Zibis at gmx.de  Sat Feb 27 18:11:05 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 27 Feb 2010 19:11:05 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and 	6815768 (String.hashCode)
In-Reply-To: <SNT114-W16D4D0A7D28AD7F6A6EC56833E0@phx.gbl>
References: <4B86B8A4.8050709@sun.com>	<4B86BF2E.8030208@sun.com>,
	<4B86CAC5.4050405@sun.com>	<4B86DAE1.5050208@gmx.de>,
	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>,
	<4B87C563.5070609@sun.com>	<4B87E7E4.7030202@gmx.de>,
	<4B87F265.4010307@gmx.de>	<4B8821D0.40803@sun.com>,
	<4B8856DE.3040908@gmx.de>,
	<5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>
	<SNT114-W16D4D0A7D28AD7F6A6EC56833E0@phx.gbl>
Message-ID: <4B896039.9030403@gmx.de>

Hm, hashCode7() has exactly the same program logic than hashCode1(), but 
by different syntax.
hashCode8() should be worse than hashCode7(), because it loads the count 
variable twice.

If you compare the byte code by javah or jclasslib bytecode viewer (very 
nice tool), you will see that, am I wrong ?

-Ulf


Am 27.02.2010 18:50, schrieb Jason Mehrens:
> Here are two more variants you might want to throw into the benchmark.
>
>   public int hashCode6() {
>         int h = hash;
>         if (h == 0 && count > 0) {
>             int off = offset;
>             char val[] = value;
>             int len = count;
>
>             for (int i = 0; i < len; i++) {
>                 h = 31*h + val[off++];
>             }
>             hash = h;
>         }
>         return h;
>   }
>
>   public int hashCode7() {
>         int h = hash;
>         int len;
>         if (h == 0 && (len = count) > 0) {
>             int off = offset;
>             char val[] = value;
>
>             for (int i = 0; i < len; i++) {
>                 h = 31*h + val[off++];
>             }
>             hash = h;
>         }
>         return h;
>   }
>
> Jason
>
>
> ------------------------------------------------------------------------
> Date: Sat, 27 Feb 2010 17:00:14 +0300
> Subject: Re: Need reviewer for forward port of 6815768 
> (File.getXXXSpace) and 6815768 (String.hashCode)
> From: dmitry.nadezhin at gmail.com
> To: core-libs-dev at openjdk.java.net
>
> Ulf,
>
> I ran Caliper benchmarks on different variants of hashCode().
> http://code.google.com/p/caliper/
> The results and the Caliper code are below:
>
>   -Dima
>
> --------- -d32 -clien
>  0% Scenario{vm=java -d32 -client, benchmark=HashCodeEmpty} 8,85ns; 
> ?=0,06ns @ 3 trials
>  8% Scenario{vm=java -d32 -client, benchmark=HashCode1Empty} 7,20ns; 
> ?=0,04ns @ 3 trials
> 17% Scenario{vm=java -d32 -client, benchmark=HashCode2Empty} 7,79ns; 
> ?=0,32ns @ 10 trials
> 25% Scenario{vm=java -d32 -client, benchmark=HashCode3Empty} 7,88ns; 
> ?=0,31ns @ 10 trials
> 33% Scenario{vm=java -d32 -client, benchmark=HashCode4Empty} 7,92ns; 
> ?=0,31ns @ 10 trials
> 42% Scenario{vm=java -d32 -client, benchmark=HashCode5Empty} 7,06ns; 
> ?=0,27ns @ 10 trials
> 50% Scenario{vm=java -d32 -client, benchmark=HashCodeLong} 145,22ns; 
> ?=0,68ns @ 3 trials
> 58% Scenario{vm=java -d32 -client, benchmark=HashCode1Long} 144,58ns; 
> ?=0,55ns @ 3 trials
> 67% Scenario{vm=java -d32 -client, benchmark=HashCode2Long} 167,55ns; 
> ?=1,58ns @ 6 trials
> 75% Scenario{vm=java -d32 -client, benchmark=HashCode3Long} 122,87ns; 
> ?=0,34ns @ 3 trials
> 83% Scenario{vm=java -d32 -client, benchmark=HashCode4Long} 122,69ns; 
> ?=0,36ns @ 3 trials
> 92% Scenario{vm=java -d32 -client, benchmark=HashCode5Long} 126,11ns; 
> ?=0,77ns @ 3 trials
>
>      benchmark   ns logarithmic runtime
>  HashCodeEmpty    9 X|||||||||||
> HashCode1Empty    7 X||||||||||
> HashCode2Empty    8 X|||||||||||
> HashCode3Empty    8 X|||||||||||
> HashCode4Empty    8 X|||||||||||
> HashCode5Empty    7 X||||||||||
>   HashCodeLong  145 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
>  HashCode1Long  145 XXXXXXXXXXXXXXXXXXXXXXXXX||||
>  HashCode2Long  168 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>  HashCode3Long  123 XXXXXXXXXXXXXXXXXXXXXX||||||
>  HashCode4Long  123 XXXXXXXXXXXXXXXXXXXXX|||||||
>  HashCode5Long  126 XXXXXXXXXXXXXXXXXXXXXX||||||
>
> vm: java -d32 -client
> --------
> -------- -d32 -server
>  0% Scenario{vm=java -d32 -server, benchmark=HashCodeEmpty} 1,69ns; 
> ?=0,01ns @ 3 trials
>  8% Scenario{vm=java -d32 -server, benchmark=HashCode1Empty} 2,00ns; 
> ?=0,07ns @ 10 trials
> 17% Scenario{vm=java -d32 -server, benchmark=HashCode2Empty} 1,97ns; 
> ?=0,01ns @ 3 trials
> 25% Scenario{vm=java -d32 -server, benchmark=HashCode3Empty} 1,55ns; 
> ?=0,01ns @ 3 trials
> 33% Scenario{vm=java -d32 -server, benchmark=HashCode4Empty} 1,54ns; 
> ?=0,01ns @ 3 trials
> 42% Scenario{vm=java -d32 -server, benchmark=HashCode5Empty} 2,32ns; 
> ?=0,01ns @ 3 trials
> 50% Scenario{vm=java -d32 -server, benchmark=HashCodeLong} 113,01ns; 
> ?=5,69ns @ 10 trials
> 58% Scenario{vm=java -d32 -server, benchmark=HashCode1Long} 101,49ns; 
> ?=0,89ns @ 3 trials
> 67% Scenario{vm=java -d32 -server, benchmark=HashCode2Long} 102,93ns; 
> ?=0,26ns @ 3 trials
> 75% Scenario{vm=java -d32 -server, benchmark=HashCode3Long} 100,29ns; 
> ?=0,98ns @ 3 trials
> 83% Scenario{vm=java -d32 -server, benchmark=HashCode4Long} 100,00ns; 
> ?=0,94ns @ 5 trials
> 92% Scenario{vm=java -d32 -server, benchmark=HashCode5Long} 112,29ns; 
> ?=1,22ns @ 10 trials
>
>      benchmark   ns logarithmic runtime
>  HashCodeEmpty    2 |||
> HashCode1Empty    2 ||||
> HashCode2Empty    2 ||||
> HashCode3Empty    2 ||
> HashCode4Empty    2 ||
> HashCode5Empty    2 |||||
>   HashCodeLong  113 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>  HashCode1Long  101 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
>  HashCode2Long  103 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
>  HashCode3Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
>  HashCode4Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
>  HashCode5Long  112 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> vm: java -d32 -server
> ------
> ------ -d64 -client
>  0% Scenario{vm=java -d64 -client, benchmark=HashCodeEmpty} 1,63ns; 
> ?=0,01ns @ 3 trials
>  8% Scenario{vm=java -d64 -client, benchmark=HashCode1Empty} 1,41ns; 
> ?=0,01ns @ 3 trials
> 17% Scenario{vm=java -d64 -client, benchmark=HashCode2Empty} 1,40ns; 
> ?=0,01ns @ 3 trials
> 25% Scenario{vm=java -d64 -client, benchmark=HashCode3Empty} 1,42ns; 
> ?=0,01ns @ 3 trials
> 33% Scenario{vm=java -d64 -client, benchmark=HashCode4Empty} 1,40ns; 
> ?=0,00ns @ 3 trials
> 42% Scenario{vm=java -d64 -client, benchmark=HashCode5Empty} 4,29ns; 
> ?=0,11ns @ 10 trials
> 50% Scenario{vm=java -d64 -client, benchmark=HashCodeLong} 101,74ns; 
> ?=0,12ns @ 3 trials
> 58% Scenario{vm=java -d64 -client, benchmark=HashCode1Long} 102,66ns; 
> ?=0,91ns @ 3 trials
> 67% Scenario{vm=java -d64 -client, benchmark=HashCode2Long} 100,41ns; 
> ?=0,45ns @ 3 trials
> 75% Scenario{vm=java -d64 -client, benchmark=HashCode3Long} 97,41ns; 
> ?=0,57ns @ 3 trials
> 83% Scenario{vm=java -d64 -client, benchmark=HashCode4Long} 97,92ns; 
> ?=0,46ns @ 3 trials
> 92% Scenario{vm=java -d64 -client, benchmark=HashCode5Long} 107,27ns; 
> ?=0,97ns @ 3 trials
>
>      benchmark   ns logarithmic runtime
>  HashCodeEmpty    2 |||
> HashCode1Empty    1 ||
> HashCode2Empty    1 ||
> HashCode3Empty    1 ||
> HashCode4Empty    1 ||
> HashCode5Empty    4 X||||||||
>   HashCodeLong  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
>  HashCode1Long  103 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
>  HashCode2Long  100 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
>  HashCode3Long   97 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
>  HashCode4Long   98 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
>  HashCode5Long  107 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> vm: java -d64 -client
> -------
> ------ -d64 -server
>  0% Scenario{vm=java -d64 -server, benchmark=HashCodeEmpty} 1,62ns; 
> ?=0,00ns @ 3 trials
>  8% Scenario{vm=java -d64 -server, benchmark=HashCode1Empty} 1,42ns; 
> ?=0,00ns @ 3 trials
> 17% Scenario{vm=java -d64 -server, benchmark=HashCode2Empty} 1,42ns; 
> ?=0,01ns @ 3 trials
> 25% Scenario{vm=java -d64 -server, benchmark=HashCode3Empty} 1,42ns; 
> ?=0,00ns @ 3 trials
> 33% Scenario{vm=java -d64 -server, benchmark=HashCode4Empty} 1,41ns; 
> ?=0,01ns @ 3 trials
> 42% Scenario{vm=java -d64 -server, benchmark=HashCode5Empty} 4,20ns; 
> ?=0,03ns @ 3 trials
> 50% Scenario{vm=java -d64 -server, benchmark=HashCodeLong} 102,05ns; 
> ?=0,22ns @ 3 trials
> 58% Scenario{vm=java -d64 -server, benchmark=HashCode1Long} 102,33ns; 
> ?=0,62ns @ 3 trials
> 67% Scenario{vm=java -d64 -server, benchmark=HashCode2Long} 100,70ns; 
> ?=0,43ns @ 3 trials
> 75% Scenario{vm=java -d64 -server, benchmark=HashCode3Long} 96,92ns; 
> ?=0,90ns @ 3 trials
> 83% Scenario{vm=java -d64 -server, benchmark=HashCode4Long} 98,22ns; 
> ?=0,40ns @ 3 trials
> 92% Scenario{vm=java -d64 -server, benchmark=HashCode5Long} 108,22ns; 
> ?=1,45ns @ 10 trials
>
>      benchmark   ns logarithmic runtime
>  HashCodeEmpty    2 |||
> HashCode1Empty    1 ||
> HashCode2Empty    1 ||
> HashCode3Empty    1 ||
> HashCode4Empty    1 ||
> HashCode5Empty    4 X||||||||
>   HashCodeLong  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
>  HashCode1Long  102 XXXXXXXXXXXXXXXXXXXXXXXXXXXX|
>  HashCode2Long  101 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
>  HashCode3Long   97 XXXXXXXXXXXXXXXXXXXXXXXXXX|||
>  HashCode4Long   98 XXXXXXXXXXXXXXXXXXXXXXXXXXX||
>  HashCode5Long  108 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> vm: java -d64 -server
> -------------
> ------------- StringHashCodeBenchmark.java
> package examples;
>
> import com.google.caliper.SimpleBenchmark;
> import java_lang.String;
>
> public class StringHashCodeBenchmark extends SimpleBenchmark {
>
>     private String EMPTY = new String("");
>     private String LONG = new 
> String("@ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ");
>
>     public int timeHashCodeEmpty(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += EMPTY.hashCode();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode1Empty(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += EMPTY.hashCode1();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode2Empty(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += EMPTY.hashCode2();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode3Empty(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += EMPTY.hashCode3();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode4Empty(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += EMPTY.hashCode4();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode5Empty(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += EMPTY.hashCode5();
>         }
>         return dummy;
>     }
>
>     public int timeHashCodeLong(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += LONG.substring(1).hashCode();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode1Long(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += LONG.substring(1).hashCode1();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode2Long(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += LONG.substring(1).hashCode2();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode3Long(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += LONG.substring(1).hashCode3();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode4Long(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += LONG.substring(1).hashCode4();
>         }
>         return dummy;
>     }
>
>     public int timeHashCode5Long(int reps) {
>         int dummy = 0;
>         for (int i = 0; i < reps; i++) {
>             dummy += LONG.substring(1).hashCode5();
>         }
>         return dummy;
>     }
> }
> ----------------
>
> On Sat, Feb 27, 2010 at 2:18 AM, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Am 26.02.2010 20:32, schrieb Alan Bateman:
>
>         Ulf Zibis wrote:
>         For these other suggestions it would be great to create
>         micro-benchmarks and try our your changes.
>
>         For now though, as I said, I'm just fixing the method to avoid the
>         store for the empty string case.
>
>
>     Here the benchmark for my different approaches on non-empty strings:
>
>     hashCode() warmup =     38,227 ms
>     hashCode1() warmup =    323,462 ms
>     hashCode() time =     12,066 ms
>     hashCode1() time =     11,620 ms
>     hashCodes sum = 0
>     hashCode() warmup =     34,928 ms
>     hashCode1() warmup =     19,010 ms
>     hashCode2() warmup =     25,938 ms
>     hashCode3() warmup =     22,428 ms
>     hashCode4() warmup =     22,966 ms
>     hashCode5() warmup =     21,372 ms
>     hashCode() time =    418,962 ms
>     hashCode1() time =    306,977 ms
>     hashCode2() time =    296,899 ms
>     hashCode3() time =    363,364 ms
>     hashCode4() time =    286,098 ms
>     hashCode5() time =    269,519 ms
>     hashCodes sum = -1427881024
>
>     See new revision:
>     https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup
>     <https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=955&view=markup>
>
>     -Ulf
>
>
>
>
>
>
> ------------------------------------------------------------------------
> Hotmail: Powerful Free email with security by Microsoft. Get it now. 
> <http://clk.atdmt.com/GBL/go/201469230/direct/01/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100227/de11c82c/attachment.html>

From alan.bateman at sun.com  Sat Feb 27 18:19:24 2010
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Sat, 27 Feb 2010 18:19:24 +0000
Subject: hg: jdk7/tl/jdk: 6929532: (file) WatchService should avoid queuing
	new modify events when lots of files are changing
Message-ID: <20100227182017.5B7DE41AB3@hg.openjdk.java.net>

Changeset: 77beb60b39c6
Author:    alanb
Date:      2010-02-27 18:18 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/77beb60b39c6

6929532: (file) WatchService should avoid queuing new modify events when lots of files are changing
Reviewed-by: alanb
Contributed-by: sebastian.sickelmann at gmx.de

! src/share/classes/sun/nio/fs/AbstractWatchKey.java
+ test/java/nio/file/WatchService/LotsOfEvents.java
- test/java/nio/file/WatchService/OverflowEventIsLoner.java



From Ulf.Zibis at gmx.de  Sat Feb 27 18:31:00 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 27 Feb 2010 19:31:00 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and 	6815768 (String.hashCode)
In-Reply-To: <5a8e758b1002260727s50255830sa66c6cde29117e16@mail.gmail.com>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>	<4B86DBDC.9090703@sun.com>
	<4B86F490.60704@sun.com>	<4B87A019.30105@gmx.de>	<5a8e758b1002260352y4cc21efdo18615f0da9e385aa@mail.gmail.com>	<4B87E689.50608@gmx.de>
	<5a8e758b1002260727s50255830sa66c6cde29117e16@mail.gmail.com>
Message-ID: <4B8964E4.90501@gmx.de>

Am 26.02.2010 16:27, schrieb Dmitry Nadezhin:
>
>
> On Fri, Feb 26, 2010 at 6:19 PM, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Am 26.02.2010 12:52, schrieb Dmitry Nadezhin:
>
>         I found two alternatives in the link
>         http://mail.openjdk.java.net/pipermail/coin-dev/2009-December/002618.html
>           The first alternative
>         int equalByHashThreshold = 2;
>
>         public boolean equals(Object anObject) {
>           if (this == anObject) {
>             return true;
>           }
>           if (anObject instanceof String) {
>
>             String anotherString = (String)anObject;
>             int n = count;
>             if (n == anotherString.count&&
>                 (equalByHashThreshold == 0 || --equalByHashThreshold
>         == 0)&&
>                 (anotherString.equalByHashThreshold == 0 ||
>         --anotherString.equalByHashThreshold == 0)&&
>
>
>                 hash() == anotherString.hash()) {
>         [snipped]
>             }
>           }
>           return false;
>         }
>
>         will say that
>         "A".equals("A") == false
>         because body of if statement will not be executed
>
>
>     I don't understand your problem.
>     1. String literals are always interned, so "A" is always identical
>     to "A". Therefore the body of the 1st if will return true.
>     2. If the strings are not identical, body of 2nd if will be
>     executed, if anObject is instance of String.
>
>
> I'm sorry. The example should be
> new String("A").equals("A") == false .
> In this case Strings are not identical. The first if wil not return.
> The second if will be executed.
> The third if will not be executed because
> (equalByHashThreshold == 0 || --equalByHashThreshhold == 0) <=> (2 == 
> 0 || 1 == 0) <=> false .
>

Thanks for your patience.
As I think, adding a new member variable to String is a bad idea, even 
if it's transient, I didn't try to fix your claim.

But I've added a new equals4() method, which too follows the idea of 
incrementing a counter against a threshold, double-using the hash value, 
but without possibility to adjust the threshold against the string's length.

See new revision:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=959&view=markup 


-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100227/38bc8fa6/attachment.html>

From alan.bateman at sun.com  Sat Feb 27 19:17:31 2010
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Sat, 27 Feb 2010 19:17:31 +0000
Subject: hg: jdk7/tl/jdk: 6929259: Remove double spaces from Dual-pivot
	quicksort
Message-ID: <20100227191749.BB57441AC3@hg.openjdk.java.net>

Changeset: b77e94f5a601
Author:    alanb
Date:      2010-02-27 19:15 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b77e94f5a601

6929259: Remove double spaces from Dual-pivot quicksort
Reviewed-by: alanb
Contributed-by: vladimir.yaroslavskiy at sun.com

! src/share/classes/java/util/DualPivotQuicksort.java



From jason_mehrens at hotmail.com  Sat Feb 27 20:57:57 2010
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Sat, 27 Feb 2010 14:57:57 -0600
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and 	6815768 (String.hashCode)
In-Reply-To: <4B896039.9030403@gmx.de>
References: <4B86B8A4.8050709@sun.com>
	<4B86BF2E.8030208@sun.com>,<4B86CAC5.4050405@sun.com>
	<4B86DAE1.5050208@gmx.de>, <SNT114-W1F6BA90892B5059181C1183400@phx.gbl>,
	<4B87C563.5070609@sun.com>
	<4B87E7E4.7030202@gmx.de>,<4B87F265.4010307@gmx.de>
	<4B8821D0.40803@sun.com>, <4B8856DE.3040908@gmx.de>,
	<5a8e758b1002270600j71a9dff8t84bc4cf0262f5032@mail.gmail.com>
	<SNT114-W16D4D0A7D28AD7F6A6EC56833E0@phx.gbl>, <4B896039.9030403@gmx.de>
Message-ID: <SNT114-W5032BF30F8BDD38585C8AB833E0@phx.gbl>



Javap shows different byte code for hashCode7 vs hashCode1 when I compiled and compared them.  I'll have not tried jclasslib.

 

I agree with you on version 7 should be faster than version 6.  However, in version 6 count is only loaded twice when running the path rarely chosen.  I think that makes version 6 a good candidate to benchmark.

 

Jason
 


Date: Sat, 27 Feb 2010 19:11:05 +0100
From: Ulf.Zibis at gmx.de
To: jason_mehrens at hotmail.com
CC: dmitry.nadezhin at gmail.com; core-libs-dev at openjdk.java.net
Subject: Re: Need reviewer for forward port of 6815768 (File.getXXXSpace) and 6815768 (String.hashCode)

Hm, hashCode7() has exactly the same program logic than hashCode1(), but by different syntax.
hashCode8() should be worse than hashCode7(), because it loads the count variable twice.

If you compare the byte code by javah or jclasslib bytecode viewer (very nice tool), you will see that, am I wrong ?

-Ulf


Am 27.02.2010 18:50, schrieb Jason Mehrens: 


Here are two more variants you might want to throw into the benchmark.
 
  public int hashCode6() {
        int h = hash;
        if (h == 0 && count > 0) {
            int off = offset;
            char val[] = value;
            int len = count;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
  }
 
  public int hashCode7() {
        int h = hash;
        int len;
        if (h == 0 && (len = count) > 0) {
            int off = offset;
            char val[] = value;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
  }
 
Jason
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/201469227/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100227/69535c7d/attachment.html>

From Ulf.Zibis at gmx.de  Sat Feb 27 21:03:52 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 27 Feb 2010 22:03:52 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B8821D0.40803@sun.com>
References: <4B86B8A4.8050709@sun.com>	<4B86BF2E.8030208@sun.com>	<4B86CAC5.4050405@sun.com>	<4B86DAE1.5050208@gmx.de>	<SNT114-W1F6BA90892B5059181C1183400@phx.gbl>	<4B87C563.5070609@sun.com>	<4B87E7E4.7030202@gmx.de>	<4B87F265.4010307@gmx.de>	<4B8821D0.40803@sun.com>
Message-ID: <4B8988B8.6060201@gmx.de>

Am 26.02.2010 20:32, schrieb Alan Bateman:
> Ulf Zibis wrote:
> For these other suggestions it would be great to create
> micro-benchmarks and try our your changes.
>
> For now though, as I said, I'm just fixing the method to avoid the
> store for the empty string case.

I've added benchmark for "same" strings:

LONG.substring(1).<init>      warmup =    6.170 ms
LONG.substring(1).hashCode()  warmup =   80.545 ms
LONG.substring(1).hashCode1() warmup =   27.564 ms
LONG.substring(1).hashCode2() warmup =  103.577 ms
LONG.substring(1).hashCode3() warmup =   63.706 ms
LONG.substring(1).hashCode4() warmup =   83.302 ms
LONG.substring(1).hashCode5() warmup =   52.357 ms
LONG.substring(1).hashCode6() warmup =   86.450 ms

LONG.substring(1).<init>      time =    101.919 ms
LONG.substring(1).hashCode()  time =    931.121 ms
LONG.substring(1).hashCode1() time =    635.150 ms
LONG.substring(1).hashCode2() time =    563.309 ms
LONG.substring(1).hashCode3() time =    599.341 ms
LONG.substring(1).hashCode4() time =    581.050 ms
LONG.substring(1).hashCode5() time =    608.527 ms
LONG.substring(1).hashCode6() time =    542.390 ms
hashCodes sum = 1197450336

SAME1==SAME2<init> warmup =   98.305 ms
SAME1.equals(SAME2)  warmup =   43.749 ms
SAME1.equals1(SAME2) warmup =  154.050 ms
SAME1.equals2(SAME2) warmup =   83.096 ms
SAME1.equals3(SAME2) warmup =  348.704 ms
SAME1.equals4(SAME2) warmup =  114.798 ms
SAME1.equals5(SAME2) warmup =   77.480 ms

SAME1==SAME2<init> time =     97.395 ms
SAME1.equals(SAME2)  time =    120.363 ms
SAME1.equals1(SAME2) time =    271.393 ms
SAME1.equals2(SAME2) time =    131.297 ms
SAME1.equals3(SAME2) time =    539.923 ms
SAME1.equals4(SAME2) time =    175.093 ms
SAME1.equals5(SAME2) time =    159.624 ms

LONG1.equals(LONG2)  warmup =   41.916 ms
LONG1.equals1(LONG2) warmup =   75.950 ms
LONG1.equals2(LONG2) warmup =   65.594 ms
LONG1.equals3(LONG2) warmup =   17.908 ms
LONG1.equals4(LONG2) warmup =   16.399 ms
LONG1.equals5(LONG2) warmup =   16.334 ms

LONG1.equals(LONG2)  time =     67.612 ms
LONG1.equals1(LONG2) time =    124.927 ms
LONG1.equals2(LONG2) time =    142.572 ms
LONG1.equals3(LONG2) time =     35.580 ms
LONG1.equals4(LONG2) time =     30.342 ms
LONG1.equals5(LONG2) time =     23.478 ms

Do you have any idea, why equals1() is so much slower than equals() ??
I can't believe that the single compare 'if (n != 0)' raises the time so much.

See new revision:
https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/j7_EUC_TW/src/java/lang/String.java?rev=960&view=markup

-Ulf








From martinrb at google.com  Sun Feb 28 01:49:11 2010
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 27 Feb 2010 17:49:11 -0800
Subject: Codereview needed for #6929479
In-Reply-To: <4B86D8E4.2030001@sun.com>
References: <4B86CAE8.3080008@sun.com> <4B86D43D.4000002@sun.com>
	<4B86D6C4.4080600@sun.com> <4B86D763.8080603@sun.com>
	<4B86D8E4.2030001@sun.com>
Message-ID: <1ccfd1c11002271749x4083d249g97a95d1ce9c36402@mail.gmail.com>

On Thu, Feb 25, 2010 at 12:09, Lance J. Andersen <Lance.Andersen at sun.com> wrote:
> Going forward, should we be using sun or oracle in the property names?

It is impractical to stamp out the "sun" in the API,
even though it's "private".

There are too many references to sun.* in third party code to
consider a massive rename, and the system properties
need to match the class hierarchy.  I urge Oracle to simply keep
the sun.* and com.sun.* conventions.

Martin


From christos at zoulas.com  Sun Feb 28 02:01:57 2010
From: christos at zoulas.com (Christos Zoulas)
Date: Sat, 27 Feb 2010 21:01:57 -0500
Subject: Codereview needed for #6929479
In-Reply-To: <1ccfd1c11002271749x4083d249g97a95d1ce9c36402@mail.gmail.com>
	from Martin Buchholz (Feb 27,  5:49pm)
Message-ID: <20100228020157.1FAA656551@rebar.astron.com>

On Feb 27,  5:49pm, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: Codereview needed for #6929479

| On Thu, Feb 25, 2010 at 12:09, Lance J. Andersen <Lance.Andersen at sun.com> wrote:
| > Going forward, should we be using sun or oracle in the property names?
| 
| It is impractical to stamp out the "sun" in the API,
| even though it's "private".
| 
| There are too many references to sun.* in third party code to
| consider a massive rename, and the system properties
| need to match the class hierarchy.  I urge Oracle to simply keep
| the sun.* and com.sun.* conventions.

Not only I would like to chime in here, but I would also like to add
that we really should not start a new oracle.* and com.oracle.* hierarchies
because their only worth is vanity, and it will only make things more
difficult to organize and find.

christos


From martinrb at google.com  Sun Feb 28 02:04:53 2010
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 27 Feb 2010 18:04:53 -0800
Subject: Codereview needed for #6929479
In-Reply-To: <4B86CAE8.3080008@sun.com>
References: <4B86CAE8.3080008@sun.com>
Message-ID: <1ccfd1c11002271804w686688b6n91ead21920035f86@mail.gmail.com>

I think some documentation of the problem,
and a practical description of how users can
deal with it, is the most important thing.
Old unix-isms, like

cp test/foo.jar production/foo.jar
jar cf production/foo.jar ...
some...unix..command > production/foo.jar
rsync -a test/ production/

need to be exposed as avoidable (!) sources of SIGBUS.

I only recently learned about the following option
to rsync, which I have started using religiously
to try to reduce SIGBUS for my own customers:

       --delay-updates
              This option puts the temporary file from each updated file  into
              a holding directory until the end of the transfer, at which time
              all the files are renamed into place in rapid succession.   This
              attempts to make the updating of the files a little more atomic.
              By default the files are placed into a directory named "~tmp~"
              in  each file's destination directory, but if you've specified
              the --partial-dir option, that directory will be  used  instead.
              See  the  comments in the --partial-dir section for a discussion
              of how this ".~tmp~" dir will be excluded from the transfer, and
              what  you  can do if you want rsync to cleanup old "~tmp~" dirs
              that might  be  lying  around.   Conflicts  with  --inplace  and
              --append.

Feel free to turn this email into educational material that
might reduce the SIGBUSes real users will encounter.

Martin

On Thu, Feb 25, 2010 at 11:09, Xueming Shen <Xueming.Shen at sun.com> wrote:
>
> http://cr.openjdk.java.net/~sherman/6929479/webrev/
>
> This is a rfe to add a system property sun.zip.disableMmap to enable the end
> user to disable the mmap usage in
> Sun's java.util.zip.ZipFile implementaiton (for Solaris and Linux
> platforms).
>
> Application uses java.util.zip.ZipFile might experience SIGBUS vm crash if
> the application mistakely over-writes
> zip/jar files that are still being used, for example the application server
> repeatedly deploy the same jar file into the
> same location again and again while there is still code (running in the same
> vm) ?still accessing this particular zip/
> jar file (access the memory that mmapped the central directory of the zip
> file). While this is indeed an programming
> error in the offending application, there is situation that the end user
> really does not have the control of those
> applications and look for a workaround for the crash. With this property set
> to true (-Dsun.zip.disableMmap=true)
> the sun zipfile implementation reads in the central directory into the
> memory instead of using mmap.
>
> Thanks,
> Sherman
>


From alan.bateman at sun.com  Sun Feb 28 12:14:23 2010
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Sun, 28 Feb 2010 12:14:23 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20100228121503.D34B441BD2@hg.openjdk.java.net>

Changeset: 529d2da0aee2
Author:    alanb
Date:      2010-02-27 19:26 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/529d2da0aee2

6815768: File.getxxxSpace() methods fail for very large file systems under 32bit Java
Reviewed-by: ohair

! src/solaris/native/java/io/UnixFileSystem_md.c

Changeset: f7a6eae6e1eb
Author:    alanb
Date:      2010-02-27 19:29 +0000
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f7a6eae6e1eb

6921374: java.lang.String::hashCode() should check for count == 0 to avoid repeated stores hash = 0
Reviewed-by: darcy, ohair

! src/share/classes/java/lang/String.java



From Ulf.Zibis at gmx.de  Sun Feb 28 13:25:31 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 28 Feb 2010 14:25:31 +0100
Subject: hg: jdk7/tl/jdk: 2 new changesets
In-Reply-To: <20100228121503.D34B441BD2@hg.openjdk.java.net>
References: <20100228121503.D34B441BD2@hg.openjdk.java.net>
Message-ID: <4B8A6ECB.6060603@gmx.de>

Alan,

why don't you take? :

public int hashCode() {
int h = hash;
if (h == 0) {
-            int off = offset;
- char val[] = value;
- int len = count; - -            for (int i = 0; i < len; i++) { 
-               h = 31*h + val[off++]; -           } -            hash = h;

+ int len = count; + if (len != 0) { +                char[] val = 
value; +                int i = offset; +                for (len += i; 
i != len; i++) +                    h = 31 * h + val[i]; 
+                hash = h; +            } } return h;


-Ulf


Am 28.02.2010 13:14, schrieb alan.bateman at sun.com:
> Changeset: f7a6eae6e1eb
> Author:    alanb
> Date:      2010-02-27 19:29 +0000
> URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f7a6eae6e1eb
>
> 6921374: java.lang.String::hashCode() should check for count == 0 to avoid repeated stores hash = 0
> Reviewed-by: darcy, ohair
>
> ! src/share/classes/java/lang/String.java
>
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100228/79d0cf3d/attachment.html>

From Alan.Bateman at Sun.COM  Sun Feb 28 15:24:50 2010
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Sun, 28 Feb 2010 15:24:50 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
In-Reply-To: <4B8A6ECB.6060603@gmx.de>
References: <20100228121503.D34B441BD2@hg.openjdk.java.net>
	<4B8A6ECB.6060603@gmx.de>
Message-ID: <4B8A8AC2.2060101@sun.com>

Ulf Zibis wrote:
> Alan,
>
> why don't you take? :
> public int hashCode() {
> int h = hash;
> if (h == 0) {
> -            int off = offset;
> - char val[] = value;
> - int len = count; - -            for (int i = 0; i < len; i++) { 
> -               h = 31*h + val[off++]; -           } -            hash 
> = h;
> + int len = count; + if (len != 0) { +                char[] val = 
> value; +                int i = offset; +                for (len += 
> i; i != len; i++) +                    h = 31 * h + val[i]; 
> +                hash = h; +            } } return h;
>
> -Ulf
The fix we have is fine and eliminates the problematic store (which is 
what this bug is about). The method could be re-written as you suggest, 
and other ways too but this is slightly beyond the scope of the original 
issue (and I said, I'm just bringing forward fixes that we are missing 
and not going general String performance work). You are welcome to run 
with this, refine your benchmarks, and propose additional patches.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100228/94bf6988/attachment.html>

From Ulf.Zibis at gmx.de  Sun Feb 28 16:09:15 2010
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 28 Feb 2010 17:09:15 +0100
Subject: Need reviewer for forward port of 6815768 (File.getXXXSpace)
	and	6815768 (String.hashCode)
In-Reply-To: <4B86F490.60704@sun.com>
References: <4B86B8A4.8050709@sun.com> <4B86BF2E.8030208@sun.com>
	<4B86CAC5.4050405@sun.com> <4B86DAE1.5050208@gmx.de>
	<4B86DBDC.9090703@sun.com> <4B86F490.60704@sun.com>
Message-ID: <4B8A952B.1010007@gmx.de>

Am 25.02.2010 23:07, schrieb Alan Bateman:
> Kelly O'Hair wrote:
>> Yup.  My eyes must be tired, I didn't see that. :^(
> Too many repositories in the air at the same time. The webrev has been 
> refreshed. Thanks Ulf.
>
>

Another thought:

In the constructors of String we could initialize hash = 
Integer.MIN_VALUE except if length == 0.
Then we could stay at the fastest version:

     public int hashCode() {
         int h = hash;
         if (h == Integer.MIN_VALUE) {
             h = 0;
             char[] val = value;
             for (int i = offset, limit = count + i; i != limit; )
                 h = 31 * h + val[i++];
             hash = h;
         }
         return h;
     }

As an alternative we could use:
private static final int UNKNOWN_HASH = 1;
Justification:
Using a small value results in little shorter byte code and machine code 
footprint after compilation.
Additionally on some CPU's this likely will perform little better, but 
never worse.

Please note:
Original loop causes 2 values to increment:
             for (int i = 0; i < len; i++) {
                 h = 31*h + val[off++];
             }
This is inefficient as I have proved in a little micro-benchmark.

-Ulf