May 2016 - core-libs-dev

RFR 8147039 : Incorrect locals and operands in compiled frames
by Brent Christian 04 May '16

04 May '16

Hi, Please review this change which fixes buggy behavior (including SEGV) in the experimental LiveStackFrame feature of StackWalker. Bug: https://bugs.openjdk.java.net/browse/JDK-8147039 Webrev: http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ As suggested in the bug report, stack walking is reimplemented using javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is updated (and renamed) with a similar interface and function to vframeStream. I've also removed the now-unneeded vframeStreamCommon::java_frame() function, added by 8140450. Thanks, -Brent

3 5

RFR 8155258: VarHandle implementation improvements
by Paul Sandoz 04 May '16

04 May '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-…> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-…> The hotspot changes are really small. Is there is precedent in such cases to push through jdk9-dev rather than hs, thus speeding up the integration? There are a bunch of improvements (mostly space/time): 1) By default a VarHandle does not hold its method types for access mode methods. Instead the erased types are held on VarForm (this shared across many VH instances) and are leveraged by the guard methods (see 4). 1.1) The non-erased method types are created on demand and cached (see 3). 2) Remove the use of ClassValue to hold VarForm instances. Each VarHandle implement holds its VarForm as a static instance. MemberNames to each access mode method implementation are still calculated on construction (this can be revisited to be lazy as a further issue). 3) A VarHandle caches invoker-based MethodHandles (access mode method type prefixed with VarHandle as the first parameter) to the corresponding MemberNames held on VarForm. Such handles are used by the VarHandle.toMethodHandle, by the guard methods (see 4), or general linkers/invokers. 4) The guard methods (on VarHandleGuards) were revamped to: 4.1) leverage the erased types in 1) 4.2) optimize for the void calling case (dropping the return value) when linking to a non-void access mode method. This is an edge case but avoids surprises (e.g. dropping the return value of a CompareAndExchange). This leverages a little known fact of invokehandle linking where it is safe to drop the return value (John assures me this is safe!), and required a slight tweak to hotspot for verification under fastdebug execution. 4.3) leverage the cached invoker method handle in 3) for the case where boxing/conversion is required, with an asType transformation. This is the non-optimal path, but is much better than before since the invoker method handle is a constant. JPRT core and hotspot tests pass. Paul.

3 6

RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package
by Paul Sandoz 04 May '16

04 May '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-inte… http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-inte… This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it”. For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. JPRT core and hotspot tests pass. Paul. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html>

5 6

RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value
by nadeesh tv 04 May '16

04 May '16

Hi all, Please review a fix for Bug ID - https://bugs.openjdk.java.net/browse/JDK-8079628 Issue - Pattern 'D' is not implemented as intended by CLDR Solution - Changed the definition of 'D' to D..D 1..3 appendValue(ChronoField.DAY_OF_YEAR, n, 19, SignStyle.NORMAL) Webrev - http://cr.openjdk.java.net/~ntv/8079628/webrev.00/ <http://cr.openjdk.java.net/%7Entv/8079628/webrev.00/> -- Thanks and Regards, Nadeesh TV

3 11

RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'
by nadeesh tv 04 May '16

04 May '16

HI all, Please review a fix for Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 Issue - Pattern letters 'A' does not match the intent of LDML/CLDR Solution - Changed the definition of pattern letters 'A','n','N' Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ -- Thanks and Regards, Nadeesh TV

3 8

JDK 9 RFR of JDK-8154911: Move GCDuringIteration.java back to tier1
by Amy Lu 04 May '16

04 May '16

java/util/WeakHashMap/GCDuringIteration.java This test was failing intermittently (JDK-6842353) and demoted to tier2. Mentioned issues have been resolved and no open bug (no failure reported) till now. This patch is to move the test back to tier1. bug: https://bugs.openjdk.java.net/browse/JDK-8154911 webrev: http://cr.openjdk.java.net/~amlu/8154911/webrev.00/ Thanks, Amy --- old/test/TEST.groups 2016-04-25 10:54:59.000000000 +0800 +++ new/test/TEST.groups 2016-04-25 10:54:58.000000000 +0800 @@ -29,7 +29,6 @@ :jdk_lang \ -java/lang/ProcessHandle/TreeTest.java \ :jdk_util \ - -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ sun/nio/cs/ISO8859x.java \ @@ -39,7 +38,6 @@ tier2 = \ java/lang/ProcessHandle/TreeTest.java \ - java/util/WeakHashMap/GCDuringIteration.java \ java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ :jdk_io \

3 3

JDK 9 RFR of JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses
by joe darcy 03 May '16

03 May '16

Hello, Please review the changes to address JDK-4943627 Deprecate rounding mode integer constants in BigDecimal and their uses http://cr.openjdk.java.net/~darcy/4943627.0/ Since JDK 5, the java.math package has had a RoundMode enum to model and manage the various rounding modes used by methods in BigDecimal (and elsewhere). Those rounding modes enum constants were added in parallel to a set of integer constants in BigDecimal previously used to model rounding modes. For each BigDecimal method which took an int rounding mode constant, a sibling method was added to take a RoundMode object. As the synopsis of the bug implies, the time has come to deprecate the legacy int rounding mode constants and the method taking those ints as arguments. Thanks, -Joe

3 2

RFR 8154049: DualPivot sorting calculates incorrect runs for nearly sorted arrays
by Paul Sandoz 03 May '16

03 May '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154049-dual-pivot-sort-one-of… https://bugs.openjdk.java.net/browse/JDK-8154049 A bug was introduced with the fix for: https://bugs.openjdk.java.net/browse/JDK-8080945 Improve the performance of primitive Arrays.sort for certain patterns of array elements Certain patterns of nearly sorted data failed to sort, and surprisingly (and embarrassingly) this was not detected by existing sorting tests. It was detected by pack200 tests, but the intermittent nature of the failure at a distance meant it took a while to track this down. If the number of elements to sort is > QUICKSORT_THRESHOLD (286), then a loop over the elements is performed to count equals, ascending and descending (transformed into ascending) runs. If the number of runs is < MAX_RUN_COUNT (67) then a merge sort of the runs is performed. When the loop finishes it is necessary to clean up some edge cases to report a final run. Modifications for JDK-8080945 failed to take into account an additional case for reporting a final run (specifically a run of equals elements, in addition to the previous case of a single last element). The fix is correctly report a final run in all cases. I tried to make the code more explicit. (It might be possible to clean up the code more, but i want to get a conservative fix in). I have also modified the nearly sorted test case: - all primitive types are correctly tested based on size thresholds, specifically short/char have a lower bound, COUNTING_SORT_THRESHOLD_FOR_SHORT_OR_CHAR (3200) above which a counting sort is performed. - added a combinatorial test, where 4 (base 3) digits, each taking values of -1, 0 or 1, bound at either side a sequence of zeros of sufficient length to ensure the array size is above the quick sort threshold. This should exercise all run counting code paths In addition we have run the pack200 “test from hell” (thanks Kumar!) and this now passes without failure. Paul.

2 2

JDK 9 RFR of adding a few @jls tags to java.lang.String
by joe darcy 03 May '16

03 May '16

Hello, Please review the small patch below to add some JLS references to the string class to supplement its textual discussion of a few sections of the JLS. Thanks, -Joe --- a/src/java.base/share/classes/java/lang/String.java Fri Apr 29 16:58:00 2016 -0700 +++ b/src/java.base/share/classes/java/lang/String.java Sat Apr 30 12:32:19 2016 -0700 @@ -117,6 +117,7 @@ * @see java.lang.StringBuilder * @see java.nio.charset.Charset * @since 1.0 + * @jls 15.18.1 String Concatenation Operator + */ public final class String @@ -2979,6 +2980,7 @@ * * @return a string that has the same contents as this string, but is * guaranteed to be from a pool of unique strings. + * @jls 3.10.5 String Literals */ public native String intern();

5 4

RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy
by Frank Yuan 03 May '16

03 May '16

Hi Mandy, Joe and all Would you like to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8155514? The webrev is at: http://cr.openjdk.java.net/~fyuan/8155514/webrev.00/. It's verified with the source bundle in http://scaaa637.us.oracle.com/archive/2016/04/2016-04-26-045641.mlchung.jdk… Thanks, Frank

3 7