May 2015 - core-libs-dev

RFR 8072853: SimpleScriptContext used by NashornScriptEngine doesn't completely complies to the spec regarding exception throwing
by A. Sundararajan 18 May '15

18 May '15

Please review http://cr.openjdk.java.net/~sundar/8072853/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8072853 Thanks, -Sundar

3 5

JDK 9 RFR of JDK-8078136: Incorrect figure number in reference to Hacker's Delight book in Long.bitCount() method
by joe darcy 17 May '15

17 May '15

Hello, Please review this typo fix for JDK-8078136: Incorrect figure number in reference to Hacker's Delight book in Long.bitCount() method diff -r d40f1245a1f1 src/java.base/share/classes/java/lang/Long.java --- a/src/java.base/share/classes/java/lang/Long.java Wed May 13 14:16:46 2015 -0700 +++ b/src/java.base/share/classes/java/lang/Long.java Sun May 17 09:51:48 2015 -0700 @@ -1708,7 +1708,7 @@ * @since 1.5 */ public static int bitCount(long i) { - // HD, Figure 5-14 + // HD, Figure 5-2 i = i - ((i >>> 1) & 0x5555555555555555L); i = (i & 0x3333333333333333L) + ((i >>> 2) & 0x3333333333333333L); i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL; I verified all the other figure references between java.lang.Integer and java.lang.Long were consistent. Thanks, -Joe

2 1

RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()
by Daniel Fuchs 17 May '15

17 May '15

Hi, Please find below a patch that tries to improve the locking strategy in LogManager. The patch proposes to use a Reantrant lock to deal with configurations changes in reset() and readConfiguration(), and avoids lock contention in initializeGlobalHandlers() http://cr.openjdk.java.net/~dfuchs/webrev_8077846/webrev.00/ comments welcome, best regards, -- daniel

5 24

Re: PriorityQueue
by Martin Buchholz 16 May '15

16 May '15

Software is hard. We tried and got stuck, although the former effort can be revived. RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator) http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019124.html On Wed, May 13, 2015 at 10:17 PM, Brett Bernstein <brett.bernstein(a)gmail.com > wrote: > To whom this may concern: > I believe the list of PriorityQueue constructors has a glaring omission > that could be easily rectified. That is, there is no constructor that > takes a Collection and a Comparator. What steps should I go through to get > this suggested to be added to the class? > > Thanks, > Brett Bernstein >

8 14

RFR(s): 8078463: optimize java/util/Map/Collisions.java
by Stuart Marks 15 May '15

15 May '15

Hi all, Please review this change to optimize a test. Basically the test did string formatting for every assertion, but the string was thrown away if the assertion passed -- the most common case. The change is to do the string formatting only when an assertion fails and information needs to be printed out. Thanks to Andrey Zakharov for discovering and investigating this. Bug report: https://bugs.openjdk.java.net/browse/JDK-8078463 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8078463/webrev.0/ On my (new, fast) laptop, with JVM options -Xcomp -XX:+DeoptimizeALot -client, the unmodified test takes about 21.4 seconds to run. The modified test takes only 12.3 seconds. Note that I have added several overloads of check() with different arguments. I tried an alternative, which is a varargs version of check(): static void check(boolean cond, String fmt, Object... args) { if (cond) { pass(); } else { fail(String.format(fmt, args)); } } This of course is much simpler code, but it took 14.2 seconds, about 15% slower than the proposed version. Is the simpler code worth the slowdown? I could go either way. Thanks. s'marks

4 7

Review request for JDK-8078596: jaxp tests failed in modular jdk due to internal class access
by Frank Yuan 15 May '15

15 May '15

Hi, Joe and All This is a test bug on 9-repo-jigsaw, jaxp tests failed due to internal class access. To fix this bug, I made the following changes: 1. moved the tests which test internal APIs to separate directory and added @modules for them 2. for other tests which don't intend to test internal APIs but have some internal API dependencies: 2.1. replaced internal APIs usage with public APIs 2.2. replaced the constants defined in internal classes with local constants As Alan's suggestion, I would push the changes to jdk9/dev and ask an open review. Would you like to take a look? Any comment will be appreciated. bug: https://bugs.openjdk.java.net/browse/JDK-8078596 webrev: http://cr.openjdk.java.net/~fyuan/8078596/webrev.00/ Thanks, Frank

3 2

RFR: 8061254: SPECjvm2008-XML performance regressions in 9-b33
by Claes Redestad 15 May '15

15 May '15

Hi, 9-b33 introduced a sustained regression in SPECjvm2008 xml.transform on a number of our test setups. JDK-8058643 removed the check on value.length > 0, which means repeated calls to "".hashCode() now do a store of the calculated value (0) to the hash field. This has potential to cause excessive cache coherence traffic in xml.transform[1] Extracting the code that showed up in profiles to a micro[2] and running this in multiple threads is up to 100x slower in 9-b33 on a dual-socket machine. Adding back the check that value.length > 0 before entering the calculation loop recuperates the loss in both micro and xml.transform, but we're seeing as good or better number by simply guarding the store: Webrev: http://cr.openjdk.java.net/~redestad/8061254/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8061254 (confidential due to links to internal systems, sorry!) This additionally avoids the field store (and potential for pointless cache traffic) also on non-empty strings whose hash value happen to equals 0. Thanks! /Claes [1] See com.sun.org.apache.xml.internal.dtm.ref.ExpandedNameTable#getExpandedTypeID. [2] http://cr.openjdk.java.net/~redestad/8061254/expandedtypeid-micro.zip

5 7

RFR: 8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049
by Andrew Haley 15 May '15

15 May '15

I mixed up my nextPutIndex and nextGetIndex. Sorry. http://cr.openjdk.java.net/~aph/8079459/ This is also the cause of Bug https://bugs.openjdk.java.net/browse/JDK-8079860 Andrew.

4 12

Updating existing JDK code to use InputStream.transferTo()
by Patrick Reinhart 14 May '15

14 May '15

Hi there, A couple months ago the transferTo() method was added to the JDK. I’m regularly joining the local hacker garten and wanted to ask if it maybe would be a good task to clean up the JDK code to use this method in such a session. Would someone sponsor such changes to be checked in? I would suggest that I would post a diff for each changed class to the core-libs-dev list. Cheers Patrick

7 24

RFR: 8080344: Incorrect GPL header
by huizhe wang 14 May '15

14 May '15

Hi, The license header in these files contain an incorrect YEAR format, e.g. "Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved." where the YEAR should have been "2013,". Please review: http://cr.openjdk.java.net/~joehw/jdk9/8080344/webrev/ Thanks, Joe

2 2