Re: Request for review: 7012206

2011-09-19 Thread Alan Bateman
David Holmes wrote: This a change to a bunch of serviceability tests (shell scripts that launch the various j* tools (jps, jstatd, jstack etc)) that I'd like to push through the TL JDK repo. The changes were done by Carlos Lucasius but I'm acting as his sponsor for getting these pushed.

hg: jdk8/tl/jdk: 7091369: DatagramSocket/Limit.java failing on 8 and 7u2

2011-09-19 Thread michael . x . mcmahon
Changeset: e3d78fe803d4 Author:michaelm Date: 2011-09-19 15:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3d78fe803d4 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 Reviewed-by: chegar, alanb ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java

Re: Re : JDK 8 code review request for 7091682 Move sun.misc.FpUtils code into java.lang.Math

2011-09-19 Thread Joe Darcy
PS I've added your comment to bug 6667086 Double.doubleToLongBits(final double value) contains inefficient test for NaN. -Joe On 9/18/2011 6:15 PM, Joe Darcy wrote: Hi Jeff. I'll consider that for some possible future work. Thanks, -Joe Jeff Hain wrote: Hi. There are some possible

Re: JDK 8 code review request for 7091682 Move sun.misc.FpUtils code into java.lang.Math

2011-09-19 Thread Ulf Zibis
Without a deeper look, I discovered several ternary operators without spacing. For better readability, it would be nice to insert some spaces. :-) -Ulf Am 17.09.2011 03:52, schrieb joe.da...@oracle.com: Hello. Please review the changes to address 7091682 Move sun.misc.FpUtils code into

Codereview request for 7082884: Incorrect UTF8 conversion for sequence ED 31

2011-09-19 Thread Xueming Shen
Hi, Unicode Standard added Addition Constraints on conversion of ill-formed UTF-8 in version 5.1 [1] and updated in 6.0 again with further clarification [2] regarding how a conformance implementation should handle ill-formed UTF-8 byte sequence. Basically it says (1) the conversion process

review request (L): 7030453: JSR 292 ClassValue.get method is too slow

2011-09-19 Thread John Rose
http://cr.openjdk.java.net/~jrose/7030453/webrev.00 The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. - It does not lock the root WeakHashMap,

hg: jdk8/tl/jdk: 7091290: fails to build jdk8 b05 Embedded build

2011-09-19 Thread weijun . wang
Changeset: 8fe6d94683af Author:weijun Date: 2011-09-20 12:40 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fe6d94683af 7091290: fails to build jdk8 b05 Embedded build Reviewed-by: xuelei, dholmes ! src/share/classes/org/ietf/jgss/Oid.java

Re: Request for review: 7012206

2011-09-19 Thread David Holmes
Thanks Alan. Other failures haven't shown up thus far so for now we'll just address these ones (it improves the pass rate somewhat :) ). Could I get a second review from someone in serviceability? Thanks, David On 19/09/2011 6:57 PM, Alan Bateman wrote: David Holmes wrote: This a change to

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

2011-09-19 Thread John Rose
On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote: FYI, There's one, java.lang.Integer's cache size is tunable via JVM command line flag -XX:AutoBoxCacheMax, which in turn sets Java system property java.lang.Integer.IntegerCache.high, and affects the Integer cache size. But that's probably a