January 2012 - core-libs-dev

hg: jdk8/tl/jdk: 7123415: Some cases of network interface indexes being read incorrectly
by chris.hegarty＠oracle.com 10 Jan '12

10 Jan '12

Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi(a)oracle.com ! src/solaris/native/java/net/net_util_md.c

1 0

typo in sun.misc.VM's comment
by Krystal Mok 10 Jan '12

10 Jan '12

Hi all, Just found a little typo in sun.misc.VM: diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.java --- a/src/share/classes/sun/misc/VM.java Thu Nov 17 10:46:02 2011 -0800 +++ b/src/share/classes/sun/misc/VM.java Tue Jan 10 13:42:52 2012 +0800 @@ -167,7 +167,7 @@ // // The initial value of this field is arbitrary; during JRE initialization // it will be reset to the value specified on the command line, if any, - // otherwise to Runtime.getRuntime.maxDirectMemory(). + // otherwise to Runtime.getRuntime().maxMemory(). // private static long directMemory = 64 * 1024 * 1024; I was looking for the default max direct memory size when I found this comment. It would have been nice if this typo was fixed in 6977738. [1] Could anybody include this fix in some future commits? Regards, Kris Mok [1]: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe

3 4

Re: 100218: BigInteger staticRandom field
by Bill Pugh 10 Jan '12

10 Jan '12

OK, I actually starting this bug report when developing a course project (Paul is a student in my class). I got bit by this using Doug Lea's ParallelArray infrastructure. My code was checking which elements in an array of 300,000 long values were prime, by checking for divisibility by small primes and then constructing a BigInteger and calling isProbablePrime. But I found that using more than one thread only gave me slowdowns. After about a half day of thinking I was using the ParallelArray code incorrectly, I eventually tracked it down to a bottleneck in the SecureRandom. At first, I figured it was just a problem with the shared SecureRandom being used in the private method passesMillerRabin when no Random object is provided. Since the method is private, I couldn't provide my own Random. I wound up using reflection to bypass access control and call passesMillerRabin with a Random object stored in a thread local. In replicating my benchmarks for this email, I noticed that I was using regular old Random objects rather than SecureRandom objects (using regular Random objects was good enough for my testing). I found that if I used a ThreadLocal<SecureRandom>, I was also getting a slow down when doing parallel primality testing. I spent some time looking at the implementation of SecureRandom and of sun.security.provider.NativePRNG. The implementation of NativePRNG uses a static singleton to perform all of the work, so that looked like the concurrency bottleneck. But when I rewrote that class, it turns out that even removing all of the Java level concurrency bottlenecks, we still can't generate concurrent secure random numbers, because the NativePRNG reads /dev/urandom for each byte, and that is inherently sequential and is the bottleneck to the entire process of generating secure random numbers. So I think the right thing to do is to abandon the original patch, and instead make the following changes: add the following method to BigInteger public boolean isProbablePrime(int certainty, Random end) , which allows primality testing with arbitrary Random objects. In many cases, using a well seeded normal Random object will work just fine, and this will give users the ability to provide their own Random objects Document SecureRandom to note that all instances of SecureRandom depend on a common shared source of randomness, and thus it can be a concurrency bottlenck. Document that BigInteger.isProbablePrime(int certainty) is a concurrency bottleneck. Add java.util.concurrent.MostlySecureRandom which uses /dev/random for seeding, and uses only the SHA1PRNG implementation provided by sun.security.provider.SecureRandom to generate subsequent randomness. Feel free to pick a name other than MostlySecureRandom. After the initial seeding, calls to generate randomness using a MostlySecureRandom should not use any shared values. If this sounds reasonable, we can work out a strategy for who will do what to make this happen. Bill > > -------- Original Message -------- > Subject: Re: 100218: BigInteger staticRandom field > Date: Wed, 04 Jan 2012 10:15:10 +1000 > From: > Organization: Oracle Corporation > To: Paul Ciprich <paul.ciprich(a)gmail.com> > CC: core-libs-dev(a)openjdk.java.net > > On 4/01/2012 10:08 AM, David Holmes wrote: >> Hi Paul, >> >> For some reason this email, despite being dated Dec 14, only just >> appeared in my inbox on Jan 3! > > Oops! I missed the fact a copy of this email also turned up on Dec 15 > and that I already replied to it. > > Comments still apply. Need to understand the context in which this > becomes a bottleneck and the performance implications for non-concurrent > use. > > David > >> On 14/12/2011 12:44 AM, Paul Ciprich wrote: >>> All, >>> >>> I've created a bug report to address a scalability problem with >>> BigInteger's staticRandom field. The problem is that the shared >>> staticRandom field causes bottlenecks with parallel code. The proposed >>> solution is to change the staticRandom field to a ThreadLocal and >>> eliminate >>> the bottleneck by giving each thread its own copy of the SecureRandom >>> object. Bug 100218 contains a patch with the proposed change if it is >>> deemed acceptable. >> >> As I mention in the bug report we have to ensure that we don't add >> unacceptable overhead to the non-concurrent case. Also I'm wondering if >> anyone might be relying on the existing SecureRandom instance being shared? >> >> Can you clarify the context for the proposed fix: what code is the >> bottleneck (isProbablePrime?), under what conditions - is it a >> microbenchmark or real code? >> >> Thanks, >> David Holmes

3 2

Code review request for javadoc problem in java.lang.invoke.MethodHandle
by Joe Darcy 10 Jan '12

10 Jan '12

Hello, Please review the simple patch below to fix a javadoc problem in java.lang.invoke.MethodHandle which stems from the arguments to the {@link} javadoc tag being reversed. Once reviewed, I'll file a bug for this and push the fix. Thanks, -Joe diff -r 858038d89fd5 src/share/classes/java/lang/invoke/MethodHandle.java --- a/src/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 09 15:54:44 2012 -0800 +++ b/src/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 09 18:14:23 2012 -0800 @@ -275,7 +275,7 @@ * generates a single invokevirtual instruction with * the symbolic type descriptor indicated in the following comment. * In these examples, the helper method {@code assertEquals} is assumed to - * be a method which calls {@link Objects.equals java.util.Objects#equals} + * be a method which calls {@link java.util.Objects#equals(Object,Object) Objects.equals } * on its arguments, and asserts that the result is true. * * <h3>Exceptions</h3>

3 2

hg: jdk8/tl/jdk: 7128512: Javadoc typo in java.lang.invoke.MethodHandle
by joe.darcy＠oracle.com 10 Jan '12

10 Jan '12

Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java

1 0

Patch to expand tz checking scope in TimeZone_md.c
by Jonathan Lu 10 Jan '12

10 Jan '12

Hi core-libs-dev, In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line 626, I found that the scope of "#ifdef __solaris__" might be too narrow, since it also works for some kind of OS which I'm currently working on, such as AIX. So I suggest to just remove the '#ifdef __solaris__' and leave the "#else" to accommodate more conditions, see attachment 'patch.diff'. I think this may enhance the cross-platform ability, any ideas about this modification? Regards - Jonathan Lu

4 13

StrictMath performance improvement not ported to Math?
by Martin Desruisseaux 09 Jan '12

09 Jan '12

Hello all On December 1, 2010, "darcy" committed a slight performance improvement to the StrictMath.min/max methods with floating point arguments (commit 8aabca72877c). The calls to the doubleToLongBits(double) method were replaced by calls to the doubleToRawLongBits(double) method, and similarly for the float type. Since the call to doubleToLongBits was used only in order to determine if an argument was negative zero, and since NaN can not map to the bits pattern of -0.0, the extra cost of collapsing all NaN values to a single canonical NaN (which is the only difference between doubleToLongBits and doubleToRawLongBits) was unnecessary. However this improvement has not been ported from StrictMath to Math; the more widely-used Math class still invokes the (presumed) slower doubleToLongBits(double) method. Actually it appears that most Math / StrictMath method implementations delegate to the other class: some Math methods delegates to StrictMath (mostly the methods backed by native code), and some StrictMath methods delegate to Math (mostly the methods implemented in pure-Java). The min/max methods are an exception; their implementation is copied in both classes. Maybe this explain why the code was updated in only one class and not the other? In the patch submitted below, I propose the following changes: 1) Ported the doubleToLongBits --> doubleToRawLongBits changes from StrictMath to Math. 2) Replaced StrictMath implementations by calls to Math, in order to reduce the risk that the code of only one class is updated in the future. 3) In if statements, replaced: (a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits) by (Double.doubleToLongBits(a) == negativeZeroDoubleBits) since the later implies the former. 4) Moved the check for (a != a) from the method beginning to the last statement, which is tested only if (a <= b) were false rather than tested unconditionally in every cases. I'm not sure if it make a real performance difference however. Webrev link: http://webrev.geomatys.com/Math/min_max/index.html Regards, Martin

3 4

hg: jdk8/tl/jdk: 7128441: StrictMath performance improvement note shared with Math
by joe.darcy＠oracle.com 09 Jan '12

09 Jan '12

Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux <martin.desruisseaux(a)geomatys.fr> ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java

1 0

hg: jdk8/tl/jdk: 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space
by alan.bateman＠oracle.com 09 Jan '12

09 Jan '12

Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java

1 0

Need reviewer: ant script bug in jaxws
by Kelly O'Hair 09 Jan '12

09 Jan '12

For jdk8. Had this on my CR list for a long time. :^( Need reviewer. This is an ant script change in jaxws Minor issue of missing files: META-INF/mailcap.default META-INF/mimetypes.default In the dist/lib/classes.jar file created by the jaxws build and delivered into the jdk. 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar http://cr.openjdk.java.net/~ohair/openjdk8/jaxws-missing-files/webrev/ -kto

2 3