November 2017 - core-libs-dev

ThreadPoolExecutor and finalization
by Roger Riggs 28 Nov '17

28 Nov '17

Hi, With the deprecation of Object.finalize its time to look at its uses too see if they can be removed or mitigated. The ThreadPoolExecutor overrides finalize to shutdown the pool. A simple but incomplete step is to retain the shutdown on finalize but remove it from the specification of ThreadPoolExecutor.finalize (and remove the override). [1] For those familiar with Executors please take as look at the situation and make a recommendation or suggestion. Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8190324

9 40

Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API
by mandy chung 28 Nov '17

28 Nov '17

This is a follow-up on JDK-8189611 that defines a new public API to return a stream of versioned entries and to return the real name of a JAR entry. JDK-8189611 leaves jdeps untouched because jdeps is compiled with the boot JDK. This patch includes: (1) changes the build not to build jdk.jdeps interim module but include com.sun.tools.classfile classes in the CreateSymbol buildtool (2) replace the use of internal API with the public APIs defined by JDK-8191942 (3) remove jdk.internal.util.jar.VersonedStream class Webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/ Thanks Mandy

3 2

Which test groups to run instead of :jdk (8176838)
by Lindenmaier, Goetz 28 Nov '17

28 Nov '17

Hi, we used to run test target :jdk. This has been removed in 8176838. Which target should we run now to get the same or similar set of tests? Best regards, Goetz.

3 6

RFR (S): JDK-8191328: Avoid unnecessary overhead in CRC32C
by Dmitry Chuyko 28 Nov '17

28 Nov '17

Hello, Please review a performance enhancement for java.util.CRC32C pure Java implementation. rfe: https://bugs.openjdk.java.net/browse/JDK-8191328 webrev: http://cr.openjdk.java.net/~dchuyko/8191328/webrev.00/ some results: https://bugs.openjdk.java.net/browse/JDK-8191328?focusedCommentId=14131194&… mail thread on original implementation: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029187.ht… I made 2 changes: * Move ByteOrder.nativeOrder() branches outside of main loops. * Break xors and loads into independent pairs. In some specific cases like -Xcomp it gives 2-7x boost. The code size has not increased significantly. Changes were checked by comparison with golden checksums on different lengths of arrays and buffers, on x86 and aarch64, though both 64-bit Little-Endian. -Dmitry

4 7

RFR: jsr166 jdk10 integration wave 6
by Martin Buchholz 28 Nov '17

28 Nov '17

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ove… Thanks to Dávid Karnok and Pavel Rappo for help with SubmissionPublisher. 8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire methods throw 8187947: A race condition in SubmissionPublisher 8191069: Miscellaneous changes imported from jsr166 CVS 2017-12

1 0

RFR 8187237: Need to define the behaviour for 0 and 1 argument method type in StringConcatFactory.makeConcat
by Paul Sandoz 28 Nov '17

28 Nov '17

8186737: Lookup argument for StringConcatFactory.makeConcat & makeConcatWithConstants cannot have privileges less than PRIVATE Please review these minor specification updates to the StringConcat bootstrap methods to clarify behaviour: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186737-8187237-string-concat… (I also updated the lambda bootstrap methods in the context of 8186737) Thanks, Paul.

2 1

8181175 Stream.concat behaves like terminal operation
by Paul Sandoz 27 Nov '17

27 Nov '17

Hi, Please review this small specification classification for Stream.concat: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/… A CSR will be created. I decided to call out that Stream.concat binds to its input stream sources rather than hedging bets and being ambiguous. If we choose to add a var args concat method then it is highly unlikely we will be able to optimize for three or more streams in the same manner as we do for two streams and it would in effect be (as in the api note i added) implemented using a flat map. In that case such a method can be called out as not binding and concatenating two streams can be performed by passing an empty stream as the third argument. Thanks, Paul. diff -r 52bcd99c60f8 src/java.base/share/classes/java/util/stream/Stream.java --- a/src/java.base/share/classes/java/util/stream/Stream.java Fri Nov 17 11:56:48 2017 -0800 +++ b/src/java.base/share/classes/java/util/stream/Stream.java Fri Nov 17 12:02:13 2017 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1341,6 +1341,10 @@ * streams is parallel. When the resulting stream is closed, the close * handlers for both input streams are invoked. * + * <p>This method operates on the two input streams and binds each stream + * its source. As a result subsequent modifications to an input stream + * source may not be reflected in the concatenated stream result. + * * @implNote * Use caution when constructing streams from repeated concatenation. * Accessing an element of a deeply concatenated stream can result in deep @@ -1349,6 +1353,15 @@ * <p>Subsequent changes to the sequential/parallel execution mode of the * returned stream are not guaranteed to be propagated to the input streams. * + * @apiNote + * This method will produce an optimal concatenated stream. To achieve this + * only two input streams are accepted and each is bound to its source. + * If such restrictions are an issue then consider the alternative: create a + * stream of streams and flat-map with the identity function, for example: + * <pre>{@code + * Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s); + * }</pre> + * * @param <T> The type of stream elements * @param a the first stream * @param b the second stream

2 4

Review Request: JDK-8190911: tools/jdeps/MultiReleaseJar.java failed with java.lang.IllegalThreadStateException
by mandy chung 27 Nov '17

27 Nov '17

This is a simple test fix. The test fails because it calls Process.exitValue() but the process hasn't exited. The test should wait for the process to terminate or let it to timeout if something goes wrong. Webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190911/webrev.00/ Mandy

2 1

Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
by Schaef, Martin 27 Nov '17

27 Nov '17

We are experiencing a problem with the following test case: https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/e… Depending on which gcc version we use to compile OpenJDK, the assertion in https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/e… fails. That is, the methods java.nio.file.attribute.BasicFileAttributes.lastModifiedTime() and java.io.File.lastModified() return results with a different precision. We root-caused it to the following code block in UnixNativeDispatcher.c: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/07011844584f/src/solaris/na… The test case at the bottom of this email can be used to reproduce the behavior. When using a JDK compiled with gcc 4.1.2, the test prints: nio 1511387180000 io 1511387180000 But when using a JDK compiled with gcc 4.4.6, the code returns: nio 1511387187817 io 1511387187000 Exception in thread "main" java.lang.RuntimeException: 1511387187817 != 1511387187000 at Issue225.testLastModified(Issue225.java:33) at Issue225.main(Issue225.java:11) In comparison, the OracleJDK binaries as downloaded from the website behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure that both methods behave the same, we propose to remove the block in UnixNativeDispatcher.c (see attached patch). Cheers, Martin ### Test code to witness the behavior difference ### import java.io.File; import java.io.IOException; import java.nio.file.LinkOption; import java.nio.file.Path; import java.nio.file.attribute.BasicFileAttributeView; import java.nio.file.attribute.BasicFileAttributes; public class Issue225 { public static void main(String[] args) throws IOException { (new Issue225()).testLastModified(); } public void testLastModified() throws IOException { File file = File.createTempFile("Test", ".txt"); file.deleteOnExit(); Path nioPath = file.toPath(); BasicFileAttributes readAttributes = nioPath .getFileSystem().provider() .getFileAttributeView(nioPath, BasicFileAttributeView.class, LinkOption.NOFOLLOW_LINKS ).readAttributes(); System.out.println(readAttributes.getClass()); System.out.println("nio " + readAttributes.lastModifiedTime().toMillis()); System.out.println("io " + file.lastModified() ); if (readAttributes.lastModifiedTime().toMillis() != file.lastModified()) { throw new RuntimeException(readAttributes.lastModifiedTime().toMillis() + " != " + file.lastModified()); } } }

4 5

RFR: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151
by Seán Coffey 27 Nov '17

27 Nov '17

Looking to fix a recent regression that appeared in 8u151. Thanks goes to Sherman for the src patch. Paul Hohensee has also helped by provided some test code. I've been able to modify an existing test to mimic the behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x. Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates with the zlib version found on the OS. bug : https://bugs.openjdk.java.net/browse/JDK-8189789 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ regards, Sean.

3 4