Re: RFR 8177552: Compact Number Formatting support

2018-11-20 Thread Nishit Jain
Hi Stephen, Thanks for the comments. The NumberFormat.Style class just defines two styles and currently it is only used by CompactNumberFormat, making it a top level class would require it to be more general purpose and increases the scope. In which case evolving it at a later point of time w

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

2018-11-20 Thread David Holmes
Hi Nick, I'll leave it for core-libs and build folk to review this, but just for some background ... This is a bit of a recurring issue. We have the all encompassing: https://bugs.openjdk.java.net/browse/JDK-8165620 "Entire JDK should be built with -D_FILE_OFFSET_BITS=64" then we had the lon

RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

2018-11-20 Thread Nick Gasson
Hi, Can someone please help me review this small makefile patch to fix an issue with java.io.File::setLastModified on 32-bit systems? https://bugs.openjdk.java.net/browse/JDK-8214077 http://cr.openjdk.java.net/~njian/8214077/webrev.0/ If the file size is > 2GB so that the size won't fit in a sig

RE: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

2018-11-20 Thread Kamath, Smita
Hi Tony, Thanks for your comments. 1) This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not break the sparc intrinsic? It may work as the code is now since the sparc intrinsic will only use the first two longs in the subkeyHtbl. W

RE: RFR: 8214078: Jtreg test java/nio/file/DirectoryStream/SecureDS.java fails on ARM32

2018-11-20 Thread Nick Gasson
> This looks okay. > > (I've moved the bug to the right place, also changed the bug synopsis to > make it clear what this issue is about). Hi Alan, Thanks for looking at this. I've updated the commit message to match the new bug synopsis. Could you help me commit this? http://cr.openjdk.java.ne

Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

2018-11-20 Thread Anthony Scarpino
On 11/19/18 12:50 PM, Kamath, Smita wrote: Hi Vladimir, I’d like to contribute an optimization for GHASH Algorithm using AVX Instructions. I have tested this optimization on SKX x86_64 platform and it shows ~20–30% performance improvement for larger message sizes (for example 8k). I, smita.

Re: RFR JDK-8213909: jdeps --print-module-deps should report missing dependences

2018-11-20 Thread Mandy Chung
Hi Sundar, Per Joe's feedback on this CSR, a new `--no-recursive` option is added to restore the non-transitive behavior.  Here is the delta webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213909/webrev.01-delta Thanks Mandy On 11/19/18 9:22 AM, Mandy Chung wrote: Thanks Sundar.  He

Re: RFR: 8213033: Archive remaining primitive box caches

2018-11-20 Thread Claes Redestad
Jiangli, Alan, thanks for reviewing! /Claes On 2018-11-20 20:17, Alan Bateman wrote: On 20/11/2018 16:09, Claes Redestad wrote: Hi, this enables archiving of remaining primitive box caches, meaning contents can be mapped in from the CDS archive. These caches appear early in many applicatio

Re: RFR: 8213033: Archive remaining primitive box caches

2018-11-20 Thread Alan Bateman
On 20/11/2018 16:09, Claes Redestad wrote: Hi, this enables archiving of remaining primitive box caches, meaning contents can be mapped in from the CDS archive. These caches appear early in many applications, and bootstrapping each cache takes ~1ms without the archiving, but disappears comple

Re: RFR: 8213033: Archive remaining primitive box caches

2018-11-20 Thread Jiangli Zhou
Hi Claes, This looks great! Ship it! :) Thanks, Jiangli On 11/20/18 8:09 AM, Claes Redestad wrote: Hi, this enables archiving of remaining primitive box caches, meaning contents can be mapped in from the CDS archive. These caches appear early in many applications, and bootstrapping each c

RE: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

2018-11-20 Thread Kamath, Smita
Hi Bernd, I agree to both of your comments and will update my code with the changes. Thanks, Smita From: Bernd Eckenfels [mailto:e...@zusammenkunft.net] Sent: Monday, November 19, 2018 2:27 PM To: Kamath, Smita ; 'Vladimir Kozlov' Cc: core-libs-dev@openjdk.java.net; security-...@openjdk.java.n

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

2018-11-20 Thread Volker Simonis
On Tue, Nov 20, 2018 at 6:15 PM Thomas Stüfe wrote: > > On Tue, Nov 20, 2018 at 6:12 PM Adam Farley8 wrote: > > > > Heya Tom, > > > > "In JDK11 and JDK12, source files are compiled with -qvisibility=hidden > > when using xlc version other than 12.1. That doesn't seem to play well > > with link op

Re: RFR: [12] JDK-8209923 : Unicode 11.0.0

2018-11-20 Thread naoto . sato
Hi Rachna, The comment in CharacterData00.java.template is misleading. Those Georgian characters are not new in Unicode 11, but they are modified to have the title case characters with the same code points. Otherwise it looks OK. Naoto On 11/20/18 4:56 AM, Rachna Goel wrote: Hi, Kindly re

Re: RFR (JDK 12/java.xml) 8210722: JAXP Tests: CatalogSupport2 and CatalogSupport3 generate incorrect messages upon failure

2018-11-20 Thread Joe Wang
Thanks Lance! Joe On 11/19/18, 2:06 PM, Lance Andersen wrote: Seems OK joe On Nov 19, 2018, at 4:04 PM, Joe Wang > wrote: Hi, Please review a test patch below. The main change is removing the references to openjdk.java.net . Since the

Re: [PATCH] Windows 32-bit DLL name decoration

2018-11-20 Thread Ali İnce
Hi Alexey, I don’t have an account on JBS as I’m not an author yet, my OCA has just been processed. Would it be possible for someone with an author status to create an issue? Regards, Ali > On 19 Nov 2018, at 12:12, Alexey Ivanov wrote: > > Hi Ali, > > The fix looks good to me provided it

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

2018-11-20 Thread Thomas Stüfe
On Tue, Nov 20, 2018 at 6:12 PM Adam Farley8 wrote: > > Heya Tom, > > "In JDK11 and JDK12, source files are compiled with -qvisibility=hidden > when using xlc version other than 12.1. That doesn't seem to play well > with link option -bexpall. " > > Found that buried in one of the associated Git i

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

2018-11-20 Thread Adam Farley8
Heya Tom, "In JDK11 and JDK12, source files are compiled with -qvisibility=hidden when using xlc version other than 12.1. That doesn't seem to play well with link option -bexpall. " Found that buried in one of the associated Git issues. It appears that it's OpenJDK's use of that option that's c

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

2018-11-20 Thread Baesken, Matthias
Hi Adam , the webrev looks OK to me (not a Reviewer however). I think it will not break anything on lower xlc versions (like xlc 12.1 that we are using). Are you able to do a full successful build with this change (when using xlc 13.1) ? Do you have a chance to test with the beta-xl

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

2018-11-20 Thread Thomas Stüfe
Hi Adam, On Tue, Nov 20, 2018 at 5:12 PM Adam Farley8 wrote: > > Hi Tom, > > Sounds reasonable. I've added a webex to the bug, and here's a link to the > bug. > > https://bugs.openjdk.java.net/browse/JDK-8214063 > > This patch is required because otherwise, when building on AIX using xlc 3.1, >

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

2018-11-20 Thread Adam Farley8
Hi Tom, Sounds reasonable. I've added a webex to the bug, and here's a link to the bug. https://bugs.openjdk.java.net/browse/JDK-8214063 This patch is required because otherwise, when building on AIX using xlc 3.1, the build fails with this error: "Visibility is not allowed on a reference to

RFR: 8213033: Archive remaining primitive box caches

2018-11-20 Thread Claes Redestad
Hi, this enables archiving of remaining primitive box caches, meaning contents can be mapped in from the CDS archive. These caches appear early in many applications, and bootstrapping each cache takes ~1ms without the archiving, but disappears completely in the noise when archived. Webrev: h

Re: Extending Java Arrays/Collection Sort API

2018-11-20 Thread Laurent Bourgès
Hi Doug, That's a pleasure to read you. Le mar. 20 nov. 2018 à 13:17, Doug Lea a écrit : > On 11/20/18 2:50 AM, Laurent Bourgès wrote: > > Hi, > > Any feedback on improving Java Sort API ? > > I think most considerations await progress on value types. I posted some > ideas and links to code last

RFR: [12] JDK-8209923 : Unicode 11.0.0

2018-11-20 Thread Rachna Goel
Hi, Kindly review this enhancement to support Unicode version in JDK to 11.0.0. Bug: https://bugs.openjdk.java.net/browse/JDK-8209923 patch: http://cr.openjdk.java.net/~rgoel/JDK-8209923/webrev.02/ -- Thanks, Rachna

Re: Extending Java Arrays/Collection Sort API

2018-11-20 Thread Doug Lea
On 11/20/18 2:50 AM, Laurent Bourgès wrote: > Hi, > Any feedback on improving Java Sort API ? I think most considerations await progress on value types. I posted some ideas and links to code last summer on Valhalla list: http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-August/thread.html

Re: Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

2018-11-20 Thread Peter Levart
Ah, I see your point. Haven't read this part of your message below before. You don't know in the MultiMap code whether the key is already in the HashMap or not (so you can't choose .get() vs. .computeIfAbsent()), but  the user of the MultiMap might expect that when the MultiMap has been pre-ini

Re: RFR 4947890 : Minimize JNI upcalls in system property initialization

2018-11-20 Thread Magnus Ihse Bursie
On 2018-11-20 00:37, Roger Riggs wrote: Hi, Webrev updated in place: http://cr.openjdk.java.net/~rriggs/webrev-props-only-raw Build changes still look fine. But please, in the future, avoid updating webrevs in place, but create new ones instead. It's hopeless to figure out what has chang

Re: Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

2018-11-20 Thread Peter Levart
Hi Michael, If in your code you "know" that a particular key must be present, then why aren't you using .get(key) in that place instead of .computeIfAbsent() and trying to rely on it being a non-modifying operation? Note that in some Map implementations (WeakHashMap for example) event .get(k

Re: Should HashMap::computeIfAbsent be considered a "structural modification" for an existing key?

2018-11-20 Thread Michael Rasmussen
A quick snippet of code that shows this, by reflecting into the Map to get the table field, and see that it changes: /* --- snip --- */ package com.test; import java.lang.reflect.Field; import java.util.HashMap; import java.util.function.Function; public class Test { public static void main(S

Re: [12] RFR JDK-8211266: [TESTBUG] jdk/nio/zipfs/ZipFSTester.java failed intermittently in ZipFSTester.checkRead()

2018-11-20 Thread Amy Lu
Please review. Thanks, Amy On 2018/11/12 2:17 PM, Amy Lu wrote: Please review this test fix for jdk/nio/zipfs/ZipFSTester.java bug: https://bugs.openjdk.java.net/browse/JDK-8211266 webrev: http://cr.openjdk.java.net/~amlu/8211266/webrev.00/ Testcase testStreamChannel fails when the given "byt

Re: Re[4]: The new optimized version of Dual-Pivot Quicksort

2018-11-20 Thread Laurent Bourgès
Hi Vladimir, One short comment, see below: Le jeu. 15 nov. 2018 à 15:39, Vladimir Yaroslavskiy a écrit : > Hello, Tagir! > > I compared Radix sort with Dual-Pivot Quicksort and see > that Radix sort is faster than DPQ (on 2M elements) on random data in > twice times, > but it works slower on r