Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Brian Burkhalter
On Dec 19, 2017, at 2:36 PM, Brian Burkhalter wrote: >> You can also simplify the “for(;;) + break" into a do while loop: >> >> do { >> int nread = 0; >> ... >> } while (n > 0); > > Good suggestion but I think that this needs to be "while (n >= 0)." Updated version here: http://cr.openjdk.

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Brian Burkhalter
On Dec 19, 2017, at 2:28 PM, Paul Sandoz wrote: >> Done. Updated: http://cr.openjdk.java.net/~bpb/8193832/webrev.01/ >> > > You can also simplify the “for(;;) + break" into a do while loop: > > do { > int nread = 0; > ... > } while (n > 0); Good suggestion but I think that this needs to b

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Paul Sandoz
> On 19 Dec 2017, at 13:43, Brian Burkhalter > wrote: > > On Dec 19, 2017, at 12:52 PM, Paul Sandoz > wrote: > >> For the case of reading 2^N bytes i believe you can avoid doing a last copy >> by checking if “n < 0" within the “nread > 0” block when “nread ==

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Brian Burkhalter
On Dec 19, 2017, at 12:52 PM, Paul Sandoz wrote: > For the case of reading 2^N bytes i believe you can avoid doing a last copy > by checking if “n < 0" within the “nread > 0” block when “nread == > DEAFULT_BUFFER_SIZE”. That might close the perf gap for smaller cases. You > can also move "nrea

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Remi Forax
- Mail original - > De: "Paul Sandoz" > À: "Brian Burkhalter" > Cc: "core-libs-dev" > Envoyé: Mardi 19 Décembre 2017 21:52:03 > Objet: Re: RFR 8193832: Performance of InputStream.readAllBytes() could be > improved > Hi, > > For the case of reading 2^N bytes i believe you can avoid doi

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Paul Sandoz
Hi, For the case of reading 2^N bytes i believe you can avoid doing a last copy by checking if “n < 0" within the “nread > 0” block when “nread == DEAFULT_BUFFER_SIZE”. That might close the perf gap for smaller cases. You can also move "nread = 0” to the same block e.g.: var copy = (n < 0 &&

RFR 8193832: Performance of InputStream.readAllBytes() could be improved

2017-12-19 Thread Brian Burkhalter
https://bugs.openjdk.java.net/browse/JDK-8193832 http://cr.openjdk.java.net/~bpb/8193832/webrev.00/ The implementation of InputStream.readAllBytes() can be modified to be in general faster and to require less memory. The current implementation starts with an internal buffer of size 8192 bytes an

Re: [11] RFR 8193085 Vectorize the nio Buffer equals and compareTo implementations

2017-12-19 Thread Paul Sandoz
> On 19 Dec 2017, at 11:35, Alan Bateman wrote: > > On 18/12/2017 20:55, Paul Sandoz wrote: >> : >> There is already an assert, perhaps i can simplify this: >> >> 1) StringCharBuffer does not require special overrides. >> >> 2) Update the mismatch method: >> >> static int mismatch(CharBuffer

Re: [11] RFR 8193085 Vectorize the nio Buffer equals and compareTo implementations

2017-12-19 Thread Alan Bateman
On 18/12/2017 20:55, Paul Sandoz wrote: : There is already an assert, perhaps i can simplify this: 1) StringCharBuffer does not require special overrides. 2) Update the mismatch method: static int mismatch(CharBuffer a, int aOff, CharBuffer b, int bOff, int length) { int i = 0; // E

Thread.single_step field, anything using it?

2017-12-19 Thread Alan Bateman
I've been going through the fields in java.lang.Thread and I'm wondering if this field can be removed:     /* Whether or not to single_step this thread. */     private boolean single_step; This field was used in the original Classic VM (pre-OpenJDK history). It doesn't appear to be used in

Re: [11] RFR of 8146656: Wrong Months Array for DateFormatSymbols

2017-12-19 Thread Rachna Goel
Hi Joe, Thanks for the comments. I have updated the CSR to have @implSpec in place of @implNote. https://bugs.openjdk.java.net/browse/JDK-8191414 Regarding "An array with either 12 or 13 elements will be returned depending on whether or {@link Calendar.UNDECIMBER} is supported." , I would

Re: RFR: JDK-8193780: (ref) Remove an undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property

2017-12-19 Thread Alan Bateman
On 18/12/2017 23:14, mandy chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193780/webrev.00/ CSR:   https://bugs.openjdk.java.net/browse/JDK-8193781 This patch removes the "jdk.lang.ref.disableClearBeforeEnqueue" system property support which was added to provide an in

Re: [11] RFR of 8146656: Wrong Months Array for DateFormatSymbols

2017-12-19 Thread Rachna Goel
Hello Joe, Thanks for the review. Reason I added @implNote is that it's the case for the default implementation. Not added as a part of spec, as some implementation can just return 12 element array for same methods through the "java.text.spi.DateFormatSymbolsProvider" SPI. Thanks, Rachna O

Re: [11] RFR of 8146656: Wrong Months Array for DateFormatSymbols

2017-12-19 Thread joe darcy
Hi Rachna, On 12/19/2017 1:13 AM, Rachna Goel wrote: Hello Joe, Thanks for the review. Reason I added @implNote is that it's the case for the default implementation. Not added as a part of spec, as some implementation can just return 12 element array for same methods through the "java.text

Re: [11] RFR of 8146656: Wrong Months Array for DateFormatSymbols

2017-12-19 Thread joe darcy
Hello Rachna, On 12/18/2017 10:35 PM, Rachna Goel wrote: Hi, Kindly review API Doc fix for java.text.DateFormatSymbols. JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8146656 Webrev: http://cr.openjdk.java.net/~rgoel/8146656/webrev/ CSR: https://bugs.openjdk.java.net/browse/JDK-819141