Re: 8072784: Better spliterator implementation for BitSet.stream()

Hello! > Hi Tagir, > > In the original issue i was pondering using SIZED for smaller bit sets and > non-SIZED for larger bit sets, since we stride over the longs themselves when > calculating the size (should be intrinsic to count the set bits, at least on > x86). Supporting both is fairly

Re: RFR 8169808 Stream returning methods should specify if they are late binding

Hello! > diff -r a11577c64a1d src/java.base/share/classes/java/lang/CharSequence.java > --- a/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 > 10:50:01 2016 -0800 > +++ b/src/java.base/share/classes/java/lang/CharSequence.java Mon Nov 21 > 12:17:08 2016 -0800 > @@

JDK 9 RFR of JDK-8170158: Remove ClassLoader/platformClassLoader/DefinePlatformClass.java from ProblemList

Please review the patch to bring back java/lang/ClassLoader/platformClassLoader/DefinePlatformClass.java It's clear now that the reported failure was caused by machine wrong time setting. bug: https://bugs.openjdk.java.net/browse/JDK-8170158 Thanks, Amy --- old/test/ProblemList.txt

RFR of JDK-8153543: java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java fails intermittently

Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8153543 webrev: http://cr.openjdk.java.net/~mli/8153543/webrev.00/ Root cause: between "TestLibrary.getUnusedRandomPort()" and "UnicastRemoteObject.exportObject(impl, 0);", there is time window,

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On 11/21/16 4:27 PM, Gustavo Romero wrote: Hi Joe, On 17-11-2016 19:33, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The reason for that is because historically the Solaris compilers have had sufficient discipline and

RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi, Could the following change be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ bug:https://bugs.openjdk.java.net/browse/JDK-8170153 It enables fdlibm optimization on Linux PPC64 LE & BE and hence

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Derek, On 17-11-2016 20:47, White, Derek wrote: > Hi Joe, > > Although neither a floating point expert (as I think I've proven to you over > the years), or a gcc expert, I checked with our in-house gcc expert and got > this following answer: > > "Yes using -fno-strict-aliasing fixes

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hello, On 11/21/2016 4:34 PM, Gustavo Romero wrote: Hi Chris, On 17-11-2016 19:48, Chris Plummer wrote: The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Chris, On 17-11-2016 19:48, Chris Plummer wrote: >> The fdlibm code relies on aliasing a two-element array of int with a double >> to do bit-level reads and writes of floating-point values. As I understand >> it, the C spec allows compilers to assume >> values of different types don't

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Joe, On 17-11-2016 19:33, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers have had >>> sufficient discipline and control regarding floating-point

Re: RFR 8169808 Stream returning methods should specify if they are late binding

> On 21 Nov 2016, at 14:19, Martin Buchholz wrote: > > > > On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz wrote: > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but > > probably they should, given the implementation

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

On Mon, Nov 21, 2016 at 2:29 PM, Paul Sandoz wrote: > > A linked list based implementation could report hasNext() == false when > currentNode.next == null, but that might change before the next call to > hasNext(). AFAIK, all of our concrete implementations don't have

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

> On 21 Nov 2016, at 13:21, Martin Buchholz wrote: > > > > On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz > wrote: > > > There's the question of what to promise after a call to forEachRemaining > > (whether or not

Re: RFR 8169808 Stream returning methods should specify if they are late binding

On Mon, Nov 21, 2016 at 1:06 PM, Paul Sandoz wrote: > > > The CONCURRENT Spliterators in j.u.c. do not document late-binding, but > probably they should, given the implementation effort we've already done to > make it so. > > > > Late-binding really only applies to

Re: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

> On 21 Nov 2016, at 20:57, Martin Buchholz wrote: > > Looks good to me! +1 -Chris. > On Mon, Nov 21, 2016 at 12:52 PM, Paul Sandoz > wrote: > >> Hi, >> >> Please review specification clarifications to PriorityQueue and >> PriorityBlockingQueue

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz wrote: > > > There's the question of what to promise after a call to forEachRemaining > (whether or not an action threw). Perhaps a blanket > > """Subsequent behavior of an iterator is unspecified after a call to > this

Re: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

On 11/21/2016 03:52 PM, Paul Sandoz wrote: Hi, Please review specification clarifications to PriorityQueue and PriorityBlockingQueue for the spliterator. Ordinarily i would not specify what spliterator characteristics are not reported, but in this case given what is said about iterator I

Re: RFR 8169808 Stream returning methods should specify if they are late binding

> On 21 Nov 2016, at 12:46, Martin Buchholz wrote: > > Thanks, Paul. > > + * The stream binds to this bit set when the terminal stream operation > + * commences. If the bit set is modified during that operation then the > + * result is undefined.

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

> On 21 Nov 2016, at 12:32, Martin Buchholz wrote: > > Thanks. Seems like progress. > > The spec below seems like it could be improved, but not sure how... > > + * > + * The behavior of an iterator is unspecified if the action performs the > + * following

Re: RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

Looks good to me! On Mon, Nov 21, 2016 at 12:52 PM, Paul Sandoz wrote: > Hi, > > Please review specification clarifications to PriorityQueue and > PriorityBlockingQueue for the spliterator. Ordinarily i would not specify > what spliterator characteristics are not

RFR 8132964 Spliterator documentation on Priority(Blocking)Queue

Hi, Please review specification clarifications to PriorityQueue and PriorityBlockingQueue for the spliterator. Ordinarily i would not specify what spliterator characteristics are not reported, but in this case given what is said about iterator I think it reasonable to say it about spliterator

Re: RFR 8169808 Stream returning methods should specify if they are late binding

Thanks, Paul. + * The stream binds to this bit set when the terminal stream operation + * commences. If the bit set is modified during that operation then the + * result is undefined. (Specifically, the spliterator for the stream is + * late-binding.) It looks like the

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

Thanks. Seems like progress. The spec below seems like it could be improved, but not sure how... + * + * The behavior of an iterator is unspecified if the action performs the + * following side-effects: + * + * modifies the underlying collection; or + * calls the

RFR 8169808 Stream returning methods should specify if they are late binding

Hi, Please review this specification clarification for the stream returning methods on CharSequence and BitStream. Those methods specify that the stream is late-binding for mutable sequences. I think those are the only relevant cases, please tell me if there are more! When looking at

RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

Hi, Please review these specification clarifications to the methods Iterator.forEachRemaining and Iterator.remove. Implementations of Iterator.forEachRemaining should have some wiggle room to optimize traversal. (In hindsight we could have done a better job locking such behaviour down in Java

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

> On Nov 21, 2016, at 10:36 AM, Brent Christian > wrote: > > On 11/11/16 2:16 AM, Alan Bateman wrote: > >>> Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks,

Re: RFR 8169435 : ClassLoader.isParallelCapable is final and conflicting method may get VerifyError

On 11/11/16 2:16 AM, Alan Bateman wrote: >>> Since there is already a @CallerSensitive protected static method called "registerAsParallelCapable" for subclasses to call from their blocks, the query could be called: isRegisteredAsParallelCapable() ? I doubt this name is already taken by any

Re: RFR: jsr166 jdk9 integration wave 12

On Mon, Nov 21, 2016 at 8:47 AM, Paul Sandoz wrote: > > On 21 Nov 2016, at 07:29, Martin Buchholz wrote: > > Un-OK. Sometimes when microbenchmarking, we stumble upon a code sequence > that hotspot likes. I observed 20% improvement with the below,

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

No worries, thanks! -DrD- > Sorry for the delay, looks good. > > Kumar > >> Please review the (fairly straightforward) JDK changes needed to support >> launching JavaFX applications in a named module. >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8169289 >> >> Webrev: >>

Re: RFR: jsr166 jdk9 integration wave 12

> On 21 Nov 2016, at 07:29, Martin Buchholz wrote: > > Un-OK. Sometimes when microbenchmarking, we stumble upon a code sequence that > hotspot likes. I observed 20% improvement with the below, so switching to > that: > > public boolean tryAdvance(Consumer

Re: 8072784: Better spliterator implementation for BitSet.stream()

Hi Tagir, In the original issue i was pondering using SIZED for smaller bit sets and non-SIZED for larger bit sets, since we stride over the longs themselves when calculating the size (should be intrinsic to count the set bits, at least on x86). Supporting both is fairly simple, but you are

Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

+1 Naoto On 11/21/16 7:02 AM, Roger Riggs wrote: Look good. Thanks, Roger On 11/21/16 5:08 AM, Bhanu Gopularam wrote: Hi Nadeesh, Thanks for the review. Please find the updated webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.02/ Please note that I have used Locale.US

Re: RFR of JDK-8170049: tests under java/rmi/activation/ fail with "java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:5281" "listen, resolve")" on windows

Looks ok. Roger On 11/21/16 3:33 AM, Hamlin Li wrote: Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8170049 webrev: http://cr.openjdk.java.net/~mli/8170049/webrev.00/ The issue is weird, it only happens on windows, and reproducible. All the

Re: RFR: jsr166 jdk9 integration wave 12

Un-OK. Sometimes when microbenchmarking, we stumble upon a code sequence that hotspot likes. I observed 20% improvement with the below, so switching to that: public boolean tryAdvance(Consumer action) { Objects.requireNonNull(action); final Object[] es =

Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

Look good. Thanks, Roger On 11/21/16 5:08 AM, Bhanu Gopularam wrote: Hi Nadeesh, Thanks for the review. Please find the updated webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.02/ Please note that I have used Locale.US instead of Locale.UK as test parameters (variables)

Re: 8072784: Better spliterator implementation for BitSet.stream()

Hello! Is it necessary to report SIZED characteristic and calculate the cardinality in advance making two-pass traversal? This improves bitSet.stream().toArray() performance (also bitSet.stream().count(), but it's rare case in practice). However this is just waste of time for any other stream

RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Ah, ok, so this is fine. Best regards, Goetz. > -Original Message- > From: Erik Joelsson [mailto:erik.joels...@oracle.com] > Sent: Montag, 21. November 2016 14:27 > To: Lindenmaier, Goetz ; Vladimir Kozlov > ; build-dev

Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Hello Goetz, Thanks for trying this out. Note that the ergo* files were removed in JDK-8169001 which is currently in jdk9/dev but not yet in hs. /Erik On 2016-11-21 14:10, Lindenmaier, Goetz wrote: Hi, linuxx86_64 has the same issue. I tested it with the jdk9/hs repo:

RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Hi, linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function ServerClassMachineImpl: jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) before LIBARCHNAME Best regards, Goetz > -Original

RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images

Hi, we appreciate this change a lot, and also if /server would go away. I built and tested it on linuxppcle, aixppc and linuxs390. There is still a place that refers to a removed variables and breaks the build: jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME You can probably just

RE: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

Hi Nadeesh, Thanks for the review. Please find the updated webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.02/ Please note that I have used Locale.US instead of Locale.UK as test parameters (variables) depend on that locale. Thank you, Bhanu -Original Message- From:

RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order

JDK-8155977 updated ObjectInputStream::resolveClass, and resolveProxyClass, to work with the platform class loader, but inadvertently removed the text describing the order in which the call stack is searched, for the 'loader'. The omission, from Java SE 8, is " ... closest such method to the

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

Sorry for the delay, looks good. Kumar Please review the (fairly straightforward) JDK changes needed to support launching JavaFX applications in a named module. JBS: https://bugs.openjdk.java.net/browse/JDK-8169289 Webrev: http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/ For

RFR of JDK-8170049: tests under java/rmi/activation/ fail with "java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:5281" "listen, resolve")" on windows

Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8170049 webrev: http://cr.openjdk.java.net/~mli/8170049/webrev.00/ The issue is weird, it only happens on windows, and reproducible. All the related tests passed on windows platforms in JPRT, but