July 2016 - core-libs-dev

RFR 8154737: Rename VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange
by Paul Sandoz 11 Jul '16

11 Jul '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154737-vh-cae-volatile-rename…> This patch renames VarHandle.compareAndExchangeVolatile to VarHandle.compareAndExchange so the naming scheme is consistent with compareAndSet, and is also a little shorter. The patch is based off hs-comp to keep in sync with other recently pushed changes and avoid possible merging issues. Hence why hotspot-compiler-dev is included, although there are no changes to hotspot. CCC is approved. This issue is granted an FC exception under JEP 193. I created a follow on issue to rename the internal Unsafe methods. https://bugs.openjdk.java.net/browse/JDK-8159995 <https://bugs.openjdk.java.net/browse/JDK-8159995> But we can do that post 9. Thanks, Paul.

3 2

Typo in internal Javadoc of Pattern.Bound
by Dawid Weiss 11 Jul '16

11 Jul '16

Probably not worth a pull request -- somebody can piggyback on another change. diff -r ff7d1c47fef8 src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java Thu Jul 07 19:00:10 2016 +0000 +++ b/src/java.base/share/classes/java/util/regex/Pattern.java Mon Jul 11 12:37:38 2016 +0200 @@ -5368,7 +5368,7 @@ * Handles word boundaries. Includes a field to allow this one class to * deal with the different types of word boundaries we can match. The word * characters include underscores, letters, and digits. Non spacing marks - * can are also part of a word if they have a base character, otherwise + * are also part of a word if they have a base character, otherwise * they are ignored for purposes of finding word boundaries. */ static final class Bound extends Node { Dawid

1 0

RFR: jsr166 jdk9 integration wave 7
by Martin Buchholz 11 Jul '16

11 Jul '16

jsr166 has been pervasively modified to use VarHandles, but there are some other pending changes (that cannot be cleanly separated from VarHandle conversion). We expect this to be the last feature integration for jdk9. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ We're asking Paul to do most of the review work here, as owner of VarHandles JEP and as Oracle employee. We need approval for API changes in https://bugs.openjdk.java.net/browse/JDK-8157523 Various improvements to ForkJoin/SubmissionPublisher code https://bugs.openjdk.java.net/browse/JDK-8080603 Replace Unsafe with VarHandle in java.util.concurrent classes There is currently a VarHandle bootstrap problem with ThreadLocal/AtomicInteger that causes java/util/Locale/Bug4152725.java to fail. Again I'm hoping that Paul will figure out what to do. In the past rearranging the order of operations in <clinit> has worked for similar problems. It's not surprising we have problems, since j.u.c. needs VarHandles initialized to do work, and j.l.invoke needs j.u.c. (notably AtomicInteger and ConcurrentHashMap) to do work. Maybe we need some very low-level concurrency infrastructure that does not use VarHandles, only for bootstrap?

6 26

RFR 8161055: Remove plugin ordering by isAfter, isBefore.
by Sundararajan Athijegannathan 08 Jul '16

08 Jul '16

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

3 2

Re: Advice on cross-repo change: JDK-8160997
by Coleen Phillimore 08 Jul '16

08 Jul '16

Hi, You can send this to core-libs-dev(a)openjdk.java.net and hotspot-dev(a)openjdk.java.net The sponsor should be from the runtime group. I don't know this well enough, so I'm going to point you to Dan (and Jerry, except Jerry's not a committer). To run JPRT don't forget to use -testset hotspot and you'll get zero failures. Coleen On 7/7/16 3:30 PM, Alan Burlison wrote: > Hi, > > I've peeled another one off my wad of patches, this one gits rid of > the use of deprecated <pwd.h> and <gid.h> APIs and switches to the > POSIX ones. This works on both S11 and S12 - without it the JDK > doesn't build on S12. > > The change crosses repos so I'm looking for some advice on where best > to submit it for review? > > Files modified: > hotspot/src/os/solaris/vm/os_solaris.cpp > hotspot/src/os/solaris/vm/perfMemory_solaris.cpp > hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp > hotspot/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c > jdk/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > jdk/src/jdk.security.auth/solaris/native/libjaas/Solaris.c > jdk/src/jdk.security.auth/unix/native/libjaas/Unix.c > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160997 > > Webrev: > http://jurassic.us.oracle.com/~alanbur/jdk/JDK-8160997/ > > Webrev zip: > http://jurassic.us.oracle.com/~alanbur/jdk/JDK-8160997.zip > > Patch (also attached to bug): > http://jurassic.us.oracle.com/~alanbur/jdk/JDK-8160997.patch > > JPRT results - 1 failure, looks unrelated > http://sthjprt.uk.oracle.com/archives/2016/07/2016-07-07-172040.alanbur.get… > > > Thanks, >

2 1

RFR JDK-8133170 : Deflater.deflate with small output buffers fails
by Xueming Shen 07 Jul '16

07 Jul '16

Hi, Please help review the doc only change for this issue. issue: https://bugs.openjdk.java.net/browse/JDK-8133170 webrev: http://cr.openjdk.java.net/~sherman/8133170/webrev As explained in the zlib.h (quoted below), there are 5 bytes of flush marker being output to the output buffer repeatedly every time this method is invoked, a > 6 bytes buffer length is requested to make FULL_FLUSH and SYNC_FLUSH work. The proposed change here is to add this ">6 bytes" request into the java doc as suggested by the submitter. ----------------------------------------- If flush is set to Z_FULL_FLUSH, all output is flushed as with Z_SYNC_FLUSH, and the compression state is reset so that decompression can restart from this point if previous compressed data has been damaged or if random access is desired. Using Z_FULL_FLUSH too often can seriously degrade compression. If deflate returns with avail_out == 0, this function must be called again with the same value of the flush parameter and more output space (updated avail_out), until the flush is complete (deflate returns with non-zero avail_out). In the case of a Z_FULL_FLUSH or Z_SYNC_FLUSH, make sure that avail_out is greater than six to avoid repeated flush markers due to avail_out == 0 on return. ----------------------------------------- Thanks, Sherman

2 1

RFR: 8153044: Allow a property to control location of tzdb.dat file
by Seán Coffey 07 Jul '16

07 Jul '16

Looking to add a new implementation specific system property which would allow the user to specify the location of the tzdb.dat file. https://bugs.openjdk.java.net/browse/JDK-8153044 http://cr.openjdk.java.net/~coffeys/webrev.8153044/webrev/ -- Regards, Sean.

4 5

Improvements to BigDecimal(double, MathContext) constructor
by John Platts 07 Jul '16

07 Jul '16

Here is the current significand normalization loop below in the BigDecimal(double, MathContext) constructor: // Normalize while ((significand & 1) == 0) { // i.e., significand is even significand >>= 1; exponent++; } Here is a better way to normalize the significand in the BigDecimal(double, MathContext) constructor: int significandTz = Long.numberOfTrailingZeros(significand); significand >>= significandTz; exponent += significandTz;

2 1

Better implementation of Long.divideUnsigned and Long.remainderUnsigned
by John Platts 07 Jul '16

07 Jul '16

In the implementations of Long.divideUnsigned and Long.remainderUnsigned, there is a better way to handle the case where dividend > Long.MAX_VALUE and divisor <= Long.MAX_VALUE than doing it through a BigInteger. Here is the current implementation of Long.divideUnsigned and Long.remainderUnsigned from OpenJDK 9: /** * Returns the unsigned quotient of dividing the first argument by * the second where each argument and the result is interpreted as * an unsigned value. * * <p>Note that in two's complement arithmetic, the three other * basic arithmetic operations of add, subtract, and multiply are * bit-wise identical if the two operands are regarded as both * being signed or both being unsigned. Therefore separate {@code * addUnsigned}, etc. methods are not provided. * * @param dividend the value to be divided * @param divisor the value doing the dividing * @return the unsigned quotient of the first argument divided by * the second argument * @see #remainderUnsigned * @since 1.8 */ public static long divideUnsigned(long dividend, long divisor) { if (divisor < 0L) { // signed comparison // Answer must be 0 or 1 depending on relative magnitude // of dividend and divisor. return (compareUnsigned(dividend, divisor)) < 0 ? 0L :1L; } if (dividend > 0) // Both inputs non-negative return dividend/divisor; else { /* * For simple code, leveraging BigInteger. Longer and faster * code written directly in terms of operations on longs is * possible; see "Hacker's Delight" for divide and remainder * algorithms. */ return toUnsignedBigInteger(dividend). divide(toUnsignedBigInteger(divisor)).longValue(); } } /** * Returns the unsigned remainder from dividing the first argument * by the second where each argument and the result is interpreted * as an unsigned value. * * @param dividend the value to be divided * @param divisor the value doing the dividing * @return the unsigned remainder of the first argument divided by * the second argument * @see #divideUnsigned * @since 1.8 */ public static long remainderUnsigned(long dividend, long divisor) { if (dividend > 0 && divisor > 0) { // signed comparisons return dividend % divisor; } else { if (compareUnsigned(dividend, divisor) < 0) // Avoid explicit check for 0 divisor return dividend; else return toUnsignedBigInteger(dividend). remainder(toUnsignedBigInteger(divisor)).longValue(); } } Here is an better implementation that does not require conversion to BigInteger: /** * Returns the unsigned quotient of dividing the first argument by * the second where each argument and the result is interpreted as * an unsigned value. * * <p>Note that in two's complement arithmetic, the three other * basic arithmetic operations of add, subtract, and multiply are * bit-wise identical if the two operands are regarded as both * being signed or both being unsigned. Therefore separate {@code * addUnsigned}, etc. methods are not provided. * * @param dividend the value to be divided * @param divisor the value doing the dividing * @return the unsigned quotient of the first argument divided by * the second argument * @see #remainderUnsigned * @since 1.8 */ public static long divideUnsigned(long dividend, long divisor) { if (divisor < 0L) { // signed comparison // Answer must be 0 or 1 depending on relative magnitude // of dividend and divisor. return (compareUnsigned(dividend, divisor)) < 0 ? 0L :1L; } if (dividend > 0 || divisor <= 1) { // One of the following is true: // 1. Both inputs are positive, in which the result is equal to dividing // dividend by divisor. // 2. The divisor is equal to zero, which will result in a DivideByZeroException // being thrown. // 3. The divisor is equal to one, in which the result is equal to dividend. return dividend/divisor; } else { long rMax = divisor - 1; if(divisor != 0 && (divisor & rMax) == 0) { // divisor is power of 2 return dividend >>> Long.numberOfTrailingZeros(divisor); } // First, divide Long.MAX_VALUE + 1 by divisor. // Division of Long.MAX_VALUE + 1 by divisor is done by the following: // 1. Dividing Long.MAX_VALUE by divisor // 2. Computing the remainder of Long.MAX_VALUE by divisor // 3. Adding 1 to the remainder computed in step #2. // 4. If the remainder is equal to divisor, add 1 to the quotient and set // the remainder to zero. long q = Long.MAX_VALUE / divisor; long r = (Long.MAX_VALUE % divisor) + 1; if(r == divisor) { q++; r = 0; } // Let x2 be equal to dividend - (Long.MAX_VALUE + 1). // Compute the actual quotient and remainder of dividing dividend by divisor // by doing the following: // 1. Increment q by the quotient of dividing x2 by divisor. // 2. Increment r by the remainder of dividing x2 by divisor. // 3. If r >= divisor is true, then increment q by 1 and decrement r by divisor. long x2 = dividend & Long.MAX_VALUE; q += x2 / divisor; r += x2 % divisor; if(r >= divisor) { q++; r -= divisor; } // Return q, which is now the actual remainder of dividing dividend by divisor. return q; } } /** * Returns the unsigned remainder from dividing the first argument * by the second where each argument and the result is interpreted * as an unsigned value. * * @param dividend the value to be divided * @param divisor the value doing the dividing * @return the unsigned remainder of the first argument divided by * the second argument * @see #divideUnsigned * @since 1.8 */ public static long remainderUnsigned(long dividend, long divisor) { if (dividend > 0 && divisor > 0) { // signed comparisons return dividend % divisor; } else { if (compareUnsigned(dividend, divisor) < 0) { // Avoid explicit check for 0 divisor return dividend; } else { long rMax = divisor - 1; if(divisor != 0 && (divisor & rMax) == 0) { // divisor is power of 2 return dividend & rMax; } // First, compute the remainder of dividing Long.MAX_VALUE + 1 // This is done by doing the following: // 1. Computing the remainder of dividing Long.MAX_VALUE by divisor. // 2. Adding 1 to the remainder computed in step #1. // 3. If the remainder is equal to divisor, set the remainder to 0. long r = (Long.MAX_VALUE % divisor) + 1; if(r == divisor) { r = 0; } // Let x2 be equal to dividend - (Long.MAX_VALUE + 1). // Compute the actual remainder of dividing dividend by divisor // by doing the following: // 1. Increment r by the remainder of dividing x2 by divisor. // 2. If r >= divisor is true, then decrement r by divisor. long x2 = dividend & Long.MAX_VALUE; r += x2 % divisor; if(r >= divisor) { r -= divisor; } // Return r, which is now the actual remainder of dividing dividend by divisor. return r; } } } The updated implementations of divideUnsigned and remainderUnsigned avoid the memory allocations that are involved in doing division through BigInteger. In addition, the algorithm used to do division without going through a BigInteger is simpler than the actual implementation in the BigInteger class.

1 0

RFR: JDK-8160829 - Remove ASMPool support from jlink
by Jim Laskey (Oracle) 07 Jul '16

07 Jul '16

Much of the removed code seems unnecessary since the same functionality can be accomplished with much simpler code. An example is provided with ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin will be supplied later. Additional changes to the plugin API will supply a cross resource resolver that will make byte code optimizing code even simpler. http://cr.openjdk.java.net/~jlaskey/8160829/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8160829

4 3