hg: jdk7/tl/jdk: 7026898: DriverManager to now use CopyOnWriteArrayList

Changeset: df9991dc1f0d Author:lancea Date: 2011-03-17 11:37 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df9991dc1f0d 7026898: DriverManager to now use CopyOnWriteArrayList Reviewed-by: alanb, briangoetz ! src/share/classes/java/sql/DriverManager.java

hg: jdk7/tl/jdk: 7028422: regression: SKID miss-matching

Changeset: 320bdab4cb2a Author:xuelei Date: 2011-03-17 08:55 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/320bdab4cb2a 7028422: regression: SKID miss-matching Summary: Do not override the previous setting for initial selection. Reviewed-by: mullan ! src/share/classes/sun/

hg: jdk7/tl/jdk: 6796662: (fmt spec) Formatter spec on BigDecimal output should not reference Float a

Changeset: 3eb51bf7e859 Author:sherman Date: 2011-03-17 11:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3eb51bf7e859 6796662: (fmt spec) Formatter spec on BigDecimal output should not reference Float a Summary: updated the spec doc Reviewed-by: alanb ! src/share/classe

hg: jdk7/tl/jdk: 2 new changesets

Changeset: a8569f14121d Author:mduigou Date: 2011-03-17 13:13 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8569f14121d 7028133: Specify serialVersionUID for RegularEnumSet and JumboEnumSet Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java

Re: Now that lambdas are in, is it likely that System.arraycopy will get a lambda version?

For some definition of "in", much work remains to deliver the functionality. That said, this is the right place to propose ideas of APIs that are sensible candidates for using lambdas. Could you sketch out what you had in mind? On 3/17/2011 12:39 AM, Paulo Levi wrote: Would that ruin the ef

Re: Now that lambdas are in, is it likely that System.arraycopy will get a lambda version?

It is an open question whether we want to support extension methods on array types, and on the list for the EG to discuss. On 3/17/2011 12:50 AM, Paulo Levi wrote: Actually, doing maps and folds over arrays would be pretty cool too.

hg: jdk7/tl/jdk: 5045147: Prevent insertion of null Key into empty TreeMap (and null element into TreeSet) when no Comparator is used. Prevent insertion of key of incorrect type into empty TreeMap and

Changeset: bf37edb38fbb Author:mduigou Date: 2011-03-17 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf37edb38fbb 5045147: Prevent insertion of null Key into empty TreeMap (and null element into TreeSet) when no Comparator is used. Prevent insertion of key of incorre

Review Request -- CR6565585: Performance improvements to Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor()

Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor() all have a needless critical section, causing large slowdowns. This patch a replaces the synchronizations by volatile references. Finally, the changes remove a doubled reference to another volatile variable. This also simp

Re: Review Request -- CR6565585: Performance improvements to Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor()

Sorry folks--the webrev url: http://cr.openjdk.java.net/~mduigou/6565585/0/webrev/ Mike On Mar 17 2011, at 15:07 , Mike Duigou wrote: > Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor() all > have a needless critical section, causing large slowdowns. This patch a > repl

Re: Review Request -- CR6565585: Performance improvements to Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor()

You might consider storing the cached item in checkAccess() in a ThreadLocal instead of a static. Not only would this eliminate the volatile accesses, but it reduces the chance of a "miss" in this one-element cache, since it will then be impervious to interleavings where other threads might us

Re: Review Request -- CR6565585: Performance improvements to Method.invoke(), Contrstuctor.newInstance() and Field.getFieldAccessor()

Hi Mike, "needless critical section" is a bit of a vague way to describe what is fundamentally a change to the caching strategy :) From a synchronization perspective I concur that the new strategy is valid, but I can't comment on whether the right access check is actually being performed. In

hg: jdk7/tl/jdk: 7022382: convert pack200 library code to use try-with-resources

Changeset: 192bbf6cd5de Author:smarks Date: 2011-03-17 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/192bbf6cd5de 7022382: convert pack200 library code to use try-with-resources Reviewed-by: ksrini ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! sr