November 2017 - core-libs-dev

RFR 8191516: OutputStream.write(byte[], int, int) could have fewer parameter bounds checks
by Brian Burkhalter 21 Nov '17

21 Nov '17

https://bugs.openjdk.java.net/browse/JDK-8191516 http://cr.openjdk.java.net/~bpb/8191516/webrev.00/ Change OutputStream.write(byte[],int,int) to use the same three parameter bounds checks used by InputStream.read(byte[],int,int) instead of the five checks currently used. This change is covered by the existing test jdk/java/io/OutputStream/WriteParams.java. Thanks, Brian

2 6

[10] RFR 8186046 Minimal ConstantDynamic support
by Paul Sandoz 20 Nov '17

20 Nov '17

Hi, Please review the following patch for minimal dynamic constant support: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support… <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support…> https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046> https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good. By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex. A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository). Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments. The CSR for the VM specification is here: https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles). Any AoT-related work will be deferred to a future release. — This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte). We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches. — Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants. One test uses class file bytes produced from a modified version of asmtools. The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test. — Paul.

7 17

RFR: 8066870 Add Readable::transferTo(Appendable)
by Patrick Reinhart 19 Nov '17

19 Nov '17

Hi Roger and Alan, I incorporated the latest feedback using version 1) from this latest post: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.h… The actual webrev is here: http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00 -Patrick

2 4

RFR 8180437 Remaining renames of CAS misnomer "swap" => "set"
by Paul Sandoz 17 Nov '17

17 Nov '17

Please review a minor cleanup of internal naming: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8180437-cas-swap-to-set/webre… <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8180437-cas-swap-to-set/webre…> Paul.

2 1

RFR(XS): 8191442: Regression in LambdaFormBuffer.replaceFunctions
by Claes Redestad 17 Nov '17

17 Nov '17

Hi, in JDK-8184777, we accidentally changed behavior of replaceFunctions from testing identity to testing equality, causing a small startup regression on some sensitive benchmarks in the process[1]. Patch to salvage the recently orphaned helper function: http://cr.openjdk.java.net/~redestad/8191442/open.00/ Thanks! /Claes [1] Made worse by https://bugs.openjdk.java.net/browse/JDK-8191418

2 2

Faster Math ?
by Laurent Bourgès 17 Nov '17

17 Nov '17

Hi, The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos... Could you check if the current JDK uses C2 intrinsics or libfdm (native / JNI overhead?) and tell me if such functions are already highly optimized in jdk9 or 10 ? Some people have implemented their own fast Math like Apache Commons Math or JaFaMa libraries that are 10x faster for acos / cbrt. I wonder if I should implement my own cbrt function (cubics) in pure java as I do not need the highest accuracy but SPEED. Would it sound possible to have a JDK FastMath public API (lots faster but less accurate?) Do you know if recent CPU (intel?) have dedicated instructions for such math operations ? Why not use it instead? Maybe that's part of the new Vectorization API (panama) ? Cheers, Laurent Bourges

5 11

RFR 8176838: Remove :compact1, :compact2. :compact3, :needs_jre test groups.
by Alexandre (Shura) Iline 17 Nov '17

17 Nov '17

Hi. Please take a look on suggested change of removing obsolete test groups. Bug: https://bugs.openjdk.java.net/browse/JDK-8176838 Webrev: http://cr.openjdk.java.net/~shurailine/8176838/webrev.01 Thank you Shura

3 2

RFR 8191429 List.sort should specify the sort is stable
by Paul Sandoz 17 Nov '17

17 Nov '17

Hi, Please review the change in specification of List.sort to state the sort must be stable (CSR is already approved): Thanks, Paul. diff -r e0041b182e31 src/java.base/share/classes/java/util/List.java --- a/src/java.base/share/classes/java/util/List.java Wed Nov 08 10:27:10 2017 -0800 +++ b/src/java.base/share/classes/java/util/List.java Thu Nov 16 13:47:46 2017 -0800 @@ -442,7 +442,8 @@ /** * Sorts this list according to the order induced by the specified - * {@link Comparator}. + * {@link Comparator}. The sort is stable: this method must not + * reorder equal elements. * * All elements in this list must be mutually comparable using the * specified comparator (that is, {@code c.compare(e1, e2)} must not throw

2 1

Collections.emptyList().sort() does nothing
by Tagir Valeev 17 Nov '17

17 Nov '17

Hello! According to `List.sort` specification [1] "This list must be modifiable". According to `Collections.emptyList` specification [2] "Returns an empty list (immutable)." So I assume that `List.sort` cannot be called on `Collections.emptyList` result. However in fact this call is allowed doing nothing. Is this behavior documented somehow? Can I rely that it will not change in future Java updates? It's even more strange with `Collections.singletonList` [3] which "Returns an immutable list containing only the specified object". Obviously I cannot do: List<String> list = Collections.singletonList("foo"); ListIterator<String> it = list.listIterator(); it.next(); it.set("bar"); // UOE However list.sort(null) works perfectly. On the other hand [1] clearly says: Throws: UnsupportedOperationException - if the list's list-iterator does not support the set operation. To me it seems that emptyList and (especially) singletonList implementation does not follow the specification. Am I missing something? With best regards, Tagir Valeev. [1] https://docs.oracle.com/javase/9/docs/api/java/util/List.html#sort-java.uti… [2] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#emptyL… [3] https://docs.oracle.com/javase/9/docs/api/java/util/Collections.html#single…

9 11

RFR (JDK10/JAXP) 8191161: Reconsider generification of XPathFunction.evaluate
by huizhe wang 16 Nov '17

16 Nov '17

Hi, Please review a quick catch-up fix on 8181150: the raw type List was changed to List<Object> when it would have been more favorable if it was List<?>: src/java.xml/share/classes/javax/xml/xpath/XPathFunction.java |- public Object evaluate(List<Object> args) + public Object evaluate(List<?> args) JBS: https://bugs.openjdk.java.net/browse/JDK-8191161 Thanks, Joe |

3 3