November 2017 - core-libs-dev

RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean
by Jaroslav Tulach 27 Nov '17

27 Nov '17

Hi. I believe I have a fix for JDK-8189116 - the jdk.internal.vm.compiler.management needs only few permissions as shown in my webrev: http://cr.openjdk.java.net/~jtulach/8189116/webrev.01/ I have executed all the tests I found and it seems none of them regressed. Also the Graal Compiler MX bean is properly exposed when the built JDK is launched with ./build/linux-x64/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX: +EnableJVMCI -XX:+UseJVMCICompiler -jar ... Please take a look and review my changes. Thanks a lot. -jt

4 10

RFR: JDK8U Backport of 8154017: Shutdown hooks are racing against shutdown sequence, if System.exit()-calling thread is interrupted
by Muneer Kolarkunnu 27 Nov '17

27 Nov '17

Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017 JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041952.html JDK10 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ceeea7370651 Change w.r.t JDK9 changeset: Changed only throws Exception to throws Throwable in test case, as jdk.testlibrary.ProcessTools.executeProcess() throws Throwable in JDK8. public static void main(String[] args) throws Throwable { Testing: Tested new regression test and all core-libs regression tests on all platforms - there are no new failures. Regards, Muneer

2 1

JDK-8191706: Proposal to add Reader::transferTo(Writer)
by Patrick Reinhart 27 Nov '17

27 Nov '17

Hi there out a the review [1] for JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API. To start the discussion I got the proposed API: /** * Reads all characters from this reader and writes the characters to the * given writer in the order that they are read. On return, this reader * will be at end of the data. This method does not close either reader * or writer. * <p> * This method may block indefinitely reading from the reader, or * writing to the writer. The behavior for the case where the reader * and/or writer is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly reader and writer * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the reader or writing to the * writer, then it may do so after some characters have been read or * written. Consequently the reader may not be at end of the data and * one, or both, streams may be in an inconsistent state. It is strongly * recommended that both streams be promptly closed if an I/O error occurs. * * @param out the writer, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 10 */ public long transferTo(Writer out) throws IOException { .... } -Patrick [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050064.h…

4 8

RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile
by Per Liden 27 Nov '17

27 Nov '17

The clock and timestamp fields in SoftReference should be declared volatile. These fields are read or updated by the VM, (possibly) concurrently with the execution of Java threads. To be more specific, the timestamp field is read by the GC during reference discovery, e.g. during G1/CMS concurrent mark. The clock is updated by the GC, typically after reference processing has completed. Webrev: http://cr.openjdk.java.net/~pliden/8191859/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191859 /Per

3 3

[10] RFR: 8191813: compiler/runtime/SpreadNullArg.java fails in tier1
by Rahul Raghavan 26 Nov '17

26 Nov '17

Hi, Please review the following fix proposal for 8191813. webrev - http://cr.openjdk.java.net/~rraghavan/8191813/webrev.00/ jbs - https://bugs.openjdk.java.net/browse/JDK-8191813 -- reported issue - After the latest sync from jdk/jdk the test SpreadNullArg started to fail in tier1 on all platforms. -- Found this SpreadNullArg.java failure Caused after JDK-8157246 fix. jbs - https://bugs.openjdk.java.net/browse/JDK-8157246. 'MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior'. changeset - http://hg.openjdk.java.net/jdk/jdk/rev/76519338df34 - So now with 8157246 fix, if method handle is invoked with a null array reference, NullPointerException will be thrown. (Not IllegalArgumentException) - So above fix proposal in SpreadNullArg.java to expect NullPointerException after 8157246 changes. Thanks, Rahul

3 4

Replacement of dual-pivot quicksort in java.util.Arrays with new 3-pivot quicksort?
by David McManamon 24 Nov '17

24 Nov '17

Hi, I found the 2009 discussion and work surrounding dual-pivot quicksort fascinating. At that time, 3-pivot quicksort was described as slower; however, since then a new 3-pivot partition algorithm was published and if you want the fastest sorting time for primitives then the results are again very interesting. For an array with 10 million elements number of swaps switching to insertion sort at 47 and then not counting swaps: ~74 million 3-pivot quicksort ~74 million dual-pivot quicksort Yet the 3-pivot is 10-15% faster - cache misses are fewer and so are comparisons. Unfortunately as we follow this path some of the original elegance of the algorithm is lost so I pasted the partition algorithm below for reference. If you need faster sorting of primitives then run the code: https://github.com/dmcmanam/quicksort/blob/master/src/Quicksort.java And just uncomment the Arrays.sort line to compare against the current dual-pivot you are using. --David // Pointers a and b initially point to the first element of the array while c // and d initially point to the last element of the array. int a = lo + 2; int b = lo + 2; int c = hi - 1; int d = hi - 1; while (b <= c) { while (A[b] < q && b <= c) { if (A[b] < p) { swap(A, a, b); a++; } b++; } while (A[c] > q && b <= c) { if (A[c] > r) { swap(A, c, d); d--; } c--; } if (b <= c) { if (A[b] > r) { if (A[c] < p) { swap(A, b, a); swap(A, a, c); a++; } else { swap(A, b, c); } swap(A, c, d); b++; c--; d--; } else { if (A[c] < p) { swap(A, b, a); swap(A, a, c); a++; } else { swap(A, b, c); } b++; c--; } } } // swap the pivots to their correct positions a--; b--; c++; d++; swap(A, lo + 1, a); swap(A, a, b); a--; swap(A, lo, a); swap(A, hi, d);

1 0

RFR 8191173 : (cl) Clarify or remove "for delegation" in ClassLoader spec
by Brent Christian 24 Nov '17

24 Nov '17

Hi, Please review my change to this small bit of ClassLoader spec that can be tidied up, as noticed by Martin. Issue: https://bugs.openjdk.java.net/browse/JDK-8191173 Webrev: http://cr.openjdk.java.net/~bchristi/8191173/webrev.00/ In java.lang.ClassLoader these methods: getParent() getPlatformClassLoader() getSystemClassLoader() all state that the returned classloader is, "for delegation." For getParent() this makes sense to mention. But it seems unnecessary for the other two methods, which are static, and designed to always return the indicated classloader. The getSystemClassLoader() docs go on to immediately mention that the system classloader is the default delegation parent. Omitting the phrase makes the spec more concise. Thanks, -Brent

5 4

[10] RFR 8191404: Upgrading JDK with latest available LSR data from IANA.
by Nishit Jain 22 Nov '17

22 Nov '17

Hi, Please review the fix for JDK-8191404 Bug: https://bugs.openjdk.java.net/browse/JDK-8191404 Webrev: http://cr.openjdk.java.net/~nishjain/8191404/webrev.00/ Fix: Updated the LSR data with the version: 2017-08-15 Regards, Nishit Jain

2 3

RFR: 8187954 Update JAX-WS RI integration to latest version
by Jack Li 22 Nov '17

22 Nov '17

Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> Summary of changes: jaxws/src/java.xml.bind/share/classes/javax/xml/bind/* JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/** JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change And also contains the fixes for importing nodes for SOAPDocumentFragment Patch also contains several small bugfixes, not tracked in JBS. ---------------- Best regards Jack Li

3 13

RFR 8191736: replace javah w/ javac in jdk tests
by Alexandre (Shura) Iline 22 Nov '17

22 Nov '17

Hi. Please take look on this quick fix of removing remains of javah usages from test/jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8191736 Webrev: http://cr.openjdk.java.net/~shurailine/8191736/webrev.00/ Thank you. Shura

3 2