Re: RFR: 8226297: Dual-pivot quicksort improvements

On 8/6/19 12:47 PM, Vladimir Yaroslavskiy wrote: I moved Object sorting related stuff after primitives sorting methods to separate functionality logically. Sure, fine to keep that all together. I can move that back: http://cr.openjdk.java.net/~bchristi/8226297/webrev04/ The order of

RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries

Hi Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 , where ZipFile does not return the correct size from the CEN when the Zip64 Extended Information Extra Field is used to store the entry size The webrev can be

Re: JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

Hi Roger, Revised webev     http://cr.openjdk.java.net/~darcy/8202385.5/ Diff of last two versions below. To ease review, I elected not to reflow the paragraphs at this time to reduce the number of lines of differences between the two versions. Several platform annotation types start there

Re[2]: RFR: 8226297: Dual-pivot quicksort improvements

Hi Brent,, I moved Object sorting related stuff after primitives sorting methods to separate functionality logically. The order of methods in my version is: 1. primitives (sequential sorting) - int - long - byte - char - short - float - double 2. primitives (parallel sorting) - int - long -

Are classes generated by LambdaMetafactory special?

Hi Mandy, thanks for the deeper explanation: all this makes much sense. Greetings Raffaello >One property of a lambda proxy class is to be in the same nest as the >caller class as it's logically part of the caller class (as it may >access its private member). VM anonymous class is an

Re: RFR: 8226297: Dual-pivot quicksort improvements

Hi, Laurent I'm not sure what exactly is causing the problem, but here's my hunch: In Vladimir's version of Arrays.java: MIN_ARRAY_SORT_GRAN NaturalOrder rangeCheck got moved around, but were unchanged. In the interest of keeping the change as simple as possible, I restored these to

Re: [13] (doc-only) RFR: 8228971: Locale API doc has redundant hyphens for some parameters

HI Patrick, I think the change is fine. Not sure it is a must have for 13 but either way good to go > On Aug 6, 2019, at 12:20 PM, Patrick Concannon > wrote: > > Hi, > > Would it be possible to have my fix for JDK-8228971 reviewed? > > The is a trivial doc-only fix which removes

Re: [13] (doc-only) RFR: 8228971: Locale API doc has redundant hyphens for some parameters

Hi Patrick, Looks fine to me. Thanks for fixing the doc. Naoto On 8/6/19 9:20 AM, Patrick Concannon wrote: Hi, Would it be possible to have my fix for JDK-8228971 reviewed? The is a trivial doc-only fix which removes redundant hyphens for parameter descriptions for the Locale API doc. The

[13] (doc-only) RFR: 8228971: Locale API doc has redundant hyphens for some parameters

Hi, Would it be possible to have my fix for JDK-8228971 reviewed? The is a trivial doc-only fix which removes redundant hyphens for parameter descriptions for the Locale API doc. The intent is to push this to JDK 13. Further information on this bug can be found here:

Re: RFR: 8224974: Implement JEP 352

Hello Dmitry, On 06/08/2019 15:25, Dmitry Chuyko wrote: > One quick question about synchronization in unmappers. One of > preliminary steps for Loom was to replace monitor usage by j.u.c locks > for I/O to let fibers release carrier threads. For instance see > JDK-8222774. Does it make sense to

Re: RFR: 8224974: Implement JEP 352

Hello Dmitry, On 06/08/2019 15:50, Dmitry Chuyko wrote: > Thanks for previous detailed explanations, and great, there are now > checks for exceptions in webrev.11. Let me add just a few comments about > that. Sure, no problem. Thank you for looking at the patch. > New >

Re: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

+1 Naoto On 8/6/19 8:13 AM, Seán Coffey wrote: Looks good Ramanand. regards, Sean. On 06/08/2019 06:57, Ramanand Patil wrote: Hi all, Please review the patch for jdk13u backport of tzdata2019b integration into jdk: Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/ Bug:

Re: [13u]: RFR: 8228469: (tz) Upgrade time-zone data to tzdata2019b

Looks good Ramanand. regards, Sean. On 06/08/2019 06:57, Ramanand Patil wrote: Hi all, Please review the patch for jdk13u backport of tzdata2019b integration into jdk: Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228469 The

Re: RFR: 8224974: Implement JEP 352

Hi Andrew, Thanks for previous detailed explanations, and great, there are now checks for exceptions in webrev.11. Let me add just a few comments about that. On 8/1/19 12:49 PM, Andrew Dinn wrote: Hello Dmitry, On 01/08/2019 05:09, Dmitry Chuyko wrote: Just a small comment about the

Re: RFR: 8224974: Implement JEP 352

Hi Andrew, One quick question about synchronization in unmappers. One of preliminary steps for Loom was to replace monitor usage by j.u.c locks for I/O to let fibers release carrier threads. For instance see JDK-8222774. Does it make sense to do the same in your new unmappers code? -Dmitry

Re: RFR: 8224974: Implement JEP 352

On 06/08/2019 13:44, Aleksey Shipilev wrote: > Ah, that is exactly what I wanted. Good then, scratch the rest of my comments. > . . . > I thought that translating two separate (and statically bound) Unsafe calls, > hooking them up to > separate Unsafe leaf entries, and then suddenly going into a

Re: RFR: 8226297: Dual-pivot quicksort improvements

Hi Brent, Thank you for sponsoring this patch. I tried to compare your webrev against my latest (diff patch files) but it gives me too many changes lines. Do you have another idea to see incremental changes only ? (anyway I can compare raw files) Thanks, Laurent Le lun. 5 août 2019 à 23:43,

Re: RFR: 8224974: Implement JEP 352

On 8/6/19 2:12 PM, Andrew Dinn wrote: > On 01/08/2019 12:16, Aleksey Shipilev wrote: >> On 7/31/19 12:55 PM, Andrew Dinn wrote: >> I am more concerned that the writeback call enters the pre sync stub >> unnecessarily. > > The stub? I hope you mean when executing the native call as opposed to >

Re: RFR: 8224974: Implement JEP 352

Hi Aleksey/Boris, This is a response to both your last review posts. New webrev link is at the end. On 01/08/2019 12:16, Aleksey Shipilev wrote: > On 7/31/19 12:55 PM, Andrew Dinn wrote: . . . > I am more concerned that the writeback call enters the pre sync stub > unnecessarily. The stub? I

Re: Bug in parallel sorting of float / double

It's too bad that floating-point ordering issues that apparently no one cares about (no reports) limit performance, but the solution seems OK. Also: I've been reviewing drafts of this update for a year. They seem OK. (Although they are very much focused on details of existing primitive types;