March 2016 - core-libs-dev

RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM
by Coleen Phillimore 12 Mar '16

12 Mar '16

Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, with JVM_GetStackTraceElements that gets all the elements in the StackTraceElement[] These improvements were found during the investigation for replacing Throwable with the StackWalkAPI. This change also adds iterator for BacktraceBuilder to make changing format of backtrace easier. Tested with -testset core, RBT nightly hotspot nightly tests on all platforms, and jck tests on linux x64. Compatibility request is approved. open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/ open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot bug link https://bugs.openjdk.java.net/browse/JDK-8150778 Thanks, Coleen

6 15

JDK 9 RFR of JDK-8151750: Mark ChangingInterests.java as intermittently failing
by joe darcy 11 Mar '16

11 Mar '16

Hello, With bugs JDK-8151749 and JDK-8149082 outstanding, the test java/nio/channels/Selector/ChangingInterests.java should be marked as intermittently failing. Please review the corresponding patch below. Thanks, -Joe diff -r 0a1b582d18b3 test/java/nio/channels/Selector/ChangingInterests.java --- a/test/java/nio/channels/Selector/ChangingInterests.java Fri Mar 11 10:06:12 2016 -0800 +++ b/test/java/nio/channels/Selector/ChangingInterests.java Fri Mar 11 14:53:49 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2016, 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 @@ -23,6 +23,7 @@ /* @test * @bug 7200742 + * @key intermittent * @summary Test that Selector doesn't spin when changing interest ops */

2 1

Review request for JDK-8151063 : Typo in java.lang.invoke.StringConcatFactory
by Abhijit Roy 11 Mar '16

11 Mar '16

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8151063 Bug - Typo in java.lang.invoke.StringConcatFactory Webrev - http://cr.openjdk.java.net/~rpatil/abhi/8151063/webrev.00/ I have rectified error and updated that one. And moving forward it for review. Regards, Abhijit.

3 3

RFR: 8072727 - add variation of Stream.iterate() that's finite
by Tagir F. Valeev 11 Mar '16

11 Mar '16

Hello! I wanted to work on foldLeft, but Brian asked me to take this issue instead. So here's webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8072727/r1/ I don't like iterator-based Stream source implementations, so I made them AbstractSpliterator-based. I also implemented manually forEachRemaining as, I believe, this improves the performance in non-short-circuiting cases. I also decided to keep two flags (started and finished) to track the state. Currently existing implementation of infinite iterate() does not use started flag, but instead reads one element ahead for primitive streams. This seems wrong to me and may even lead to unexpected exceptions (*). I could get rid of "started" flag for Stream.iterate() using Streams.NONE, but this would make object implementation different from primitive implementations. It would also be possible to keep single three-state variable (byte or int, NOT_STARTED, STARTED, FINISHED), but I doubt that this would improve the performance or footprint. Having two flags looks more readable to me. Currently existing two-arg iterate methods can now be expressed as a partial case of the new method: public static<T> Stream<T> iterate(final T seed, final UnaryOperator<T> f) { return iterate(seed, x -> true, f); } (same for primitive streams). I may do this if you think it's reasonable. I created new test class and added new iterate sources to existing data providers. Please review and sponsor! With best regards, Tagir Valeev. (*) Consider the following code: int[] data = {1,2,3,4,-1}; IntStream.iterate(0, x -> data[x]) .takeWhile(x -> x >= 0) .forEach(System.out::println); Currently this unexpectedly throws an AIOOBE, because IntStream.iterate unnecessarily tries to read one element ahead.

7 21

Review request for JDK-8151062 : Unclosed parenthesis in java.util.EnumMap.clone() Javadoc
by Abhijit Roy 11 Mar '16

11 Mar '16

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8151062 Bug - Unclosed parenthesis in java.util.EnumMap.clone() Javadoc Webrev - http://cr.openjdk.java.net/~rpatil/abhi/8151062/webrev.00/ I have just rectified and closed the corresponding parenthesis. And moving forward it for review. Regards, Abhijit.

2 1

RFR(S): 8150782: findClass / accessClass throw unexpected exceptions
by Michael Haupt 11 Mar '16

11 Mar '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150782 Webrev: http://cr.openjdk.java.net/~mhaupt/8150782/webrev.00/ The unexpected exceptions turned out to be non-issues; however it was advisable to add some explanations to the API documentation. Also, the change contains some tests that illustrate these cases. CCC approval is pending. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

3 3

Review request for JDK-8151065 : Typo in javax.naming.CompoundName
by Abhijit Roy 11 Mar '16

11 Mar '16

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8151065 Bug - Typo in javax.naming.CompoundName Webrev - http://cr.openjdk.java.net/~rpatil/abhi/8151065/webrev.00/ I have just rectified and modified those error. And moving forward it for review. Regards, Abhijit

3 5

Review request for JDK-8151660: Revert NativeBuffer.java to use jdk.internal.ref.Cleaner
by Mandy Chung 10 Mar '16

10 Mar '16

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151660/webrev.00/ This is to revert NativeBuffer.java change in JDK-8149925. I can’t reliably reproduce the recursive initialization and this issue seems to be sensitive to the system configuration. JPRT build and tests are fine. I’m inclined to push this change to jdk9/dev to get tested. Mandy

3 3

RFR(XS): 8147844: new method j.l.Runtime.onSpinWait()
by Ivan Krylov 10 Mar '16

10 Mar '16

Hello, Earlier there was a discussion on this mail alias about the spin loop hint proposal [1]. Based on the feedback from that discussion some changes were incorporated and the JEP has been filed [2]. There seems to be a consensus on the API side. The JEP is now in a draft state and I hope this JEP will get targeted for java 9 shortly. Please review the upcoming API changes: http://cr.openjdk.java.net/~ikrylov/8147844.jdk.00/ For the reference, the new generated JavaDoc for j.l.Runtime class and the new method http://ivankrylov.github.io/onspinwait/api/java/lang/Runtime.html#onSpinWai… Thanks, Ivan 1 - http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/thread.ht… 2 - https://bugs.openjdk.java.net/browse/JDK-8147832.

8 19

RFR: JDK-8043329: Wrong variable used in java.util.Collections javadoc code
by Sergey Ustimenko 10 Mar '16

10 Mar '16

Hi everyone! Could someone plaese review this tiny javadoc fix and sponsor it? Patch is in attaches. diff --git a/src/java.base/share/classes/java/util/Collections.java b/src/java.base/share/classes/java/util/Collections.java --- a/src/java.base/share/classes/java/util/Collections.java +++ b/src/java.base/share/classes/java/util/Collections.java @@ -2728,7 +2728,7 @@ * Set s2 = m2.keySet(); // Needn't be in synchronized block * ... * synchronized (m) { // Synchronizing on m, not m2 or s2! - * Iterator i = s.iterator(); // Must be in synchronized block + * Iterator i = s2.iterator(); // Must be in synchronized block * while (i.hasNext()) * foo(i.next()); * }

3 3