Re: RFR: 8272297: FileInputStream should override transferTo() for better performance [v3]

2021-08-13 Thread Brian Burkhalter
> Please consider this request to add an override > `java.io.FileInputStream.transferTo(OutputStream)` with improved performance > if the parameter is a `FileOutputStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2]

2021-08-13 Thread Brian Burkhalter
On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override >> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance >> if the parameter is a `FileOutputStream`. > > Brian Burkhalter has

Re: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2]

2021-08-12 Thread Brian Burkhalter
On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote: >> Please consider this request to add an override >> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance >> if the parameter is a `FileOutputStream`. > > Brian Burkhalter has

Re: RFR: 8272297: FileInputStream should override transferTo() for better performance [v2]

2021-08-12 Thread Brian Burkhalter
> Please consider this request to add an override > `java.io.FileInputStream.transferTo(OutputStream)` with improved performance > if the parameter is a `FileOutputStream`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8263940: NPE when creating default file system when default file system provider is packaged as JAR file on class path [v2]

2021-08-12 Thread Brian Burkhalter
On Thu, 12 Aug 2021 19:24:39 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for JDK-8263940 to address an issues when the default >> file system provider is packaged as JAR file on class path. >> >> The patch also addresses the `@bug` line for JDK-8271194 >> >> Mach5 Tier1

Re: RFR: 8272297: FileInputStream should override transferTo() for better performance

2021-08-12 Thread Brian Burkhalter
On Thu, 12 Aug 2021 11:30:16 GMT, Alan Bateman wrote: >> Please consider this request to add an override >> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance >> if the parameter is a `FileOutputStream`. > > src/java.base/share/classes/java/io/FileInputStream.java line

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13]

2021-08-12 Thread Brian Burkhalter
On Wed, 11 Aug 2021 11:27:53 GMT, Alan Bateman wrote: >>> I think I fixed all requested changes. Anymore comments on this PR? >> >> I hope to get to this soon. > >> I think I fixed all requested changes. Anymore comments on this PR? > > I've looked through the latest revision. Is there any way

Re: RFR: 8272297: FileInputStream should override transferTo() for better performance

2021-08-11 Thread Brian Burkhalter
On Thu, 12 Aug 2021 01:16:04 GMT, Brian Burkhalter wrote: > Please consider this request to add an override > `java.io.FileInputStream.transferTo(OutputStream)` with improved performance > if the parameter is a `FileOutputStream`. Invoking `transferTo()` on a `FileInputStream` wil

RFR: 8272297: FileInputStream should override transferTo() for better performance

2021-08-11 Thread Brian Burkhalter
Please consider this request to add an override `java.io.FileInputStream.transferTo(OutputStream)` with improved performance if the parameter is a `FileOutputStream`. - Commit messages: - 8272297: FileInputStream should override transferTo() for better performance Changes: https:/

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13]

2021-08-11 Thread Brian Burkhalter
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a >> possible solution for issue >> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not >> yet* intended for a final review. >> >> As proposed i

Re: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v3]

2021-08-05 Thread Brian Burkhalter
On Thu, 5 Aug 2021 18:57:42 GMT, Brian Burkhalter wrote: >> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to >> `java.lang.Math` and `java.lang.StrictMath`. > > Brian Burkhalter has updated the pull request with a new target base due to a > merge

Re: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v3]

2021-08-05 Thread Brian Burkhalter
> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to > `java.lang.Math` and `java.lang.StrictMath`. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - 8271225: Verbiage update

Re: Integrated: 8271888: build error after JDK-8271599

2021-08-04 Thread Brian Burkhalter
On Wed, 4 Aug 2021 18:42:08 GMT, Joe Darcy wrote: > Remove extraneous tag to fix build breakage. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5002

Re: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4]

2021-08-04 Thread Brian Burkhalter
On Tue, 3 Aug 2021 22:44:57 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in >> all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>

Re: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v4]

2021-08-03 Thread Brian Burkhalter
On Tue, 3 Aug 2021 22:44:57 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in >> all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>

Re: RFR: 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in some places [v3]

2021-08-03 Thread Brian Burkhalter
On Tue, 3 Aug 2021 22:37:12 GMT, Raffaello Giulietti wrote: >> Hello, >> >> please review the changes in documentation of floorDiv() and floorMod() in >> all their variants. Some are clarifications, some are corrections. >> >> Here's an example of a confusing formulation in the current doc >>

Re: RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result

2021-08-03 Thread Brian Burkhalter
On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's > even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local > variable in an internal

Re: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math

2021-08-03 Thread Brian Burkhalter
On Tue, 3 Aug 2021 08:42:18 GMT, Raffaello Giulietti wrote: >> The `floorDivExact()` methods are identical to their `floorDiv()` >> counterparts aside from that they throw an `ArithmeticException` when the >> dividend is `MIN_VALUE` and the divisor is `-1`. These methods behave with >> respec

Re: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math [v2]

2021-08-02 Thread Brian Burkhalter
> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to > `java.lang.Math` and `java.lang.StrictMath`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8271225: Some verbiage updates - C

Re: RFR: 8271601: Math.floorMod(int, int) and Math.floorMod(long, long) differ in their logic

2021-08-02 Thread Brian Burkhalter
On Mon, 2 Aug 2021 19:59:57 GMT, Raffaello Giulietti wrote: > Hello, > > please review this tiny change in the implementation of > j.l.Math.floorMod(int, int). > > While the results are unaffected, all of > floorDiv(int, int) > floorDiv(long, long) > floorMod(long, long) > use x ^

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-07-29 Thread Brian Burkhalter
On Thu, 29 Jul 2021 19:56:40 GMT, Markus KARG wrote: >> It's actually a matter of convention but I think it can remain as it is. > > Ok for me, otherwise just clearly tell me and I do change it. I think you can leave it unless someone else thinks otherwise. - PR: https://git.openj

RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math

2021-07-29 Thread Brian Burkhalter
Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`. - Commit messages: - 8271225: Add floorDivExact() method to java.lang.[Strict]Math Changes: https://git.openjdk.java.net/jdk/pull/4941/files Webrev: https://webrevs.

Re: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math

2021-07-29 Thread Brian Burkhalter
On Thu, 29 Jul 2021 23:27:32 GMT, Brian Burkhalter wrote: > Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to > `java.lang.Math` and `java.lang.StrictMath`. The `floorDivExact()` methods are identical to their `floorDiv()` counterparts aside from that they th

Re: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example

2021-07-29 Thread Brian Burkhalter
On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread > example. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/293

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-07-29 Thread Brian Burkhalter
On Thu, 29 Jul 2021 08:12:23 GMT, Markus KARG wrote: >> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 179: >> >>> 177: for (long n = srcSize - srcPos; bytesWritten < n;) >>> 178: bytesWritten += src.transferTo(srcPos + bytesWritten, >>> Long.MA

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-07-26 Thread Brian Burkhalter
On Mon, 26 Jul 2021 20:45:14 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a >> possible solution for issue >> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not >> yet* intended for a final review. >> >> As proposed

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-07-26 Thread Brian Burkhalter
On Mon, 26 Jul 2021 20:45:14 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a >> possible solution for issue >> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not >> yet* intended for a final review. >> >> As proposed

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v6]

2021-07-26 Thread Brian Burkhalter
On Mon, 26 Jul 2021 20:45:14 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a >> possible solution for issue >> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not >> yet* intended for a final review. >> >> As proposed

Integrated: 8075806: divideExact is missing in java.lang.Math

2021-07-26 Thread Brian Burkhalter
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. This pull request has

Re: RFR: 8171382: java.time.Duration missing isPositive method

2021-07-23 Thread Brian Burkhalter
On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato wrote: > Please review this PR to introduce `java.time.Duration.isPositive()` method. > A CSR is also drafted. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4892

Re: RFR: 8199594: Add doc describing how (?x) ignores spaces in character classes [v3]

2021-07-23 Thread Brian Burkhalter
On Thu, 22 Jul 2021 01:46:09 GMT, Ian Graves wrote: >> 8199594: Add doc describing how (?x) ignores spaces in character classes > > Ian Graves has updated the pull request incrementally with one additional > commit since the last revision: > > Rewording repetitive phrase Marked as reviewed b

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v6]

2021-07-22 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has updated the pull request incrementally with one additional co

Integrated: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values

2021-07-22 Thread Brian Burkhalter
On Mon, 12 Jul 2021 19:39:13 GMT, Brian Burkhalter wrote: > Please consider this proposal to add some test coverage comparing `Math` and > `StrictMath` results of `pow()`. This pull request has now been integrated. Changeset: 1362e094 Author: Brian Burkhalter URL:

Re: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

2021-07-22 Thread Brian Burkhalter
On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy wrote: > Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about > annotation applicability made in java.lang.annotation.Target need to be > updated to match. > > Please also review the corresponding CSR: > https://bugs.openjdk

Re: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values [v2]

2021-07-22 Thread Brian Burkhalter
On Wed, 14 Jul 2021 16:43:48 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add some test coverage comparing `Math` and >> `StrictMath` results of `pow()`. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit si

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v5]

2021-07-22 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has updated the pull request incrementally with one additional co

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v4]

2021-07-15 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has refreshed the contents of this pull request, and previous commit

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v3]

2021-07-15 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has updated the pull request incrementally with one additional co

Re: RFR: 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

2021-07-15 Thread Brian Burkhalter
On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda wrote: > Removing unnecessary `@SuppressWarnings("exports")`. The reason for the > suppress warnings was, as far as I can tell, removed by > https://bugs.openjdk.java.net/browse/JDK-8265137. +1 - Marked as reviewed by bpb (Reviewer).

Re: RFR: 8075806: divideExact is missing in java.lang.Math

2021-07-14 Thread Brian Burkhalter
On Wed, 14 Jul 2021 16:45:20 GMT, Joe Darcy wrote: > Are there examples in the JDK or its tests where a method with this > definition would be used? I have not identified any as yet. I did verify however that there are no uses in `open/src/**/*.java` of either `absExact()` or `negateExact()`,

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v2]

2021-07-14 Thread Brian Burkhalter
On Wed, 14 Jul 2021 16:43:32 GMT, Joe Darcy wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8075806: Separate div-by-0 verbiage; change impl > > src/java.base/share/classes

Re: RFR: 8075806: divideExact is missing in java.lang.Math [v2]

2021-07-14 Thread Brian Burkhalter
> Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Brian Burkhalter has updated the pull request incrementally with one additional co

Re: RFR: 8075806: divideExact is missing in java.lang.Math

2021-07-14 Thread Brian Burkhalter
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. @rgiulietti Actually your t

Re: RFR: 8075806: divideExact is missing in java.lang.Math

2021-07-14 Thread Brian Burkhalter
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Thanks. I was thinkin

Re: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v3]

2021-07-14 Thread Brian Burkhalter
On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a >> possible solution for issue >> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not >> yet* intended for a final review. >> >> As proposed i

Re: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values [v2]

2021-07-14 Thread Brian Burkhalter
On Tue, 13 Jul 2021 23:29:38 GMT, Joe Darcy wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a >> ulp to

Re: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values [v2]

2021-07-14 Thread Brian Burkhalter
> Please consider this proposal to add some test coverage comparing `Math` and > `StrictMath` results of `pow()`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8211002: Change so that Tests.testUlpDiff() handles the Na

Integrated: 6506405: Math.abs(float) is slow

2021-07-14 Thread Brian Burkhalter
On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter wrote: > Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. This pull request has now been integrated. Changeset: c0d4efff Author: Brian Burkhalter URL:

Re: RFR: 8075806: divideExact is missing in java.lang.Math

2021-07-13 Thread Brian Burkhalter
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `divideExact()` methods for integral > data types to `java.lang.Math` thereby rounding out "exact" support to all > four basic arithmetic operations. Note: The `StrictMat

RFR: 8075806: divideExact is missing in java.lang.Math

2021-07-13 Thread Brian Burkhalter
Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations. - Commit messages: - 8075806: divideExact is missing in java.lang.Math Changes: https://git.openjd

Re: [jdk17] RFR: JDK-8270075 SplittableRandom extends AbstractSplittableGenerator

2021-07-12 Thread Brian Burkhalter
On Mon, 12 Jul 2021 14:26:23 GMT, Jim Laskey wrote: > Random.AbstractSplittableGenerator is an internal class that should not be > exposed in a public API. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/243

RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values

2021-07-12 Thread Brian Burkhalter
Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`. - Commit messages: - 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values Changes: https://git.openjdk.java.net/jdk/pull/4758/files Web

Re: RFR: 6506405: Math.abs(float) is slow [v9]

2021-07-12 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the pr

Re: RFR: 6506405: Math.abs(float) is slow [v6]

2021-07-09 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6506405: Clean up test - Changes: - all:

Re: RFR: 6506405: Math.abs(float) is slow [v7]

2021-07-09 Thread Brian Burkhalter
On Fri, 9 Jul 2021 22:02:14 GMT, Joe Darcy wrote: >> Brian Burkhalter has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. > > src/jav

Re: RFR: 6506405: Math.abs(float) is slow [v8]

2021-07-09 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6506405: More test cleanup - Changes: - all:

Re: RFR: 6506405: Math.abs(float) is slow [v7]

2021-07-09 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the pr

Re: RFR: 6506405: Math.abs(float) is slow [v5]

2021-07-09 Thread Brian Burkhalter
On Fri, 9 Jul 2021 13:54:39 GMT, Joe Darcy wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6506405: Add some tests > > test/jdk/java/lang/Math/AbsTests.java line 35: > >&g

[jdk17] Integrated: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

2021-07-08 Thread Brian Burkhalter
On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter wrote: > Modify the specification of > `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is > returned instead of `0` when the stream is at its end and the third > parameter, `len`, is zero. This pull req

Re: RFR: 6506405: Math.abs(float) is slow [v5]

2021-07-08 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6506405: Add some tests - Changes: - all:

Re: RFR: 6506405: Math.abs(float) is slow [v4]

2021-07-08 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6506405: Set MAG_BIT_MASKs to bit-wise compleme

Re: RFR: 6506405: Math.abs(float) is slow [v3]

2021-07-08 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the pr

Re: RFR: 6506405: Math.abs(float) is slow [v2]

2021-07-08 Thread Brian Burkhalter
On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter wrote: >> Please consider this change to make the `float` and `double` versions of >> `java.lang.Math.abs()` branch-free. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit si

Re: RFR: 6506405: Math.abs(float) is slow

2021-07-07 Thread Brian Burkhalter
On Jul 7, 2021, at 5:50 PM, Joe Darcy mailto:joe.da...@oracle.com>> wrote: There is no specific constant in `{Float,Double}Consts` to mask all but the sign bit, but I had thought it might be good to add one there The sign bit mask can be bit-wise complemented though :-) I had it that way in

Re: RFR: 6506405: Math.abs(float) is slow [v2]

2021-07-07 Thread Brian Burkhalter
> Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6506405: Add comments, use new consts for m

Re: RFR: 6506405: Math.abs(float) is slow

2021-07-07 Thread Brian Burkhalter
On Thu, 8 Jul 2021 00:38:45 GMT, Joe Darcy wrote: >> Please consider this change to make the `float` and `double` versions of >> `java.lang.Math.abs()` branch-free. > > src/java.base/share/classes/java/lang/Math.java line 1530: > >> 1528: @IntrinsicCandidate >> 1529: public static float

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-07-07 Thread Brian Burkhalter
On Fri, 2 Jul 2021 19:36:01 GMT, Joe Wang wrote: >> Thanks for the suggestion. I am happy with it as is, but I'll hold off >> integrating it for now and rethink it later. > > Ok, good to know. Have a great weekend! I am inclined to leave the wording alone barring serious objections to the cont

Re: RFR: 6506405: Math.abs(float) is slow

2021-07-07 Thread Brian Burkhalter
On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter wrote: > Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. On Jul 7, 2021, at 3:44 PM, Rémi Forax ***@***.**@***.***>> wrote: Your patch change the semantics, actua

Re: RFR: 6506405: Math.abs(float) is slow

2021-07-07 Thread Brian Burkhalter
On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter wrote: > Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. Good catch. Well that’s not good. If it needs to catch a special case it’s probably not worth doing. given the

RFR: 6506405: Math.abs(float) is slow

2021-07-07 Thread Brian Burkhalter
Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free. - Commit messages: - 6506405: Math.abs(float) is slow Changes: https://git.openjdk.java.net/jdk/pull/4711/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4711&r

Re: RFR: 6506405: Math.abs(float) is slow

2021-07-07 Thread Brian Burkhalter
On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter wrote: > Please consider this change to make the `float` and `double` versions of > `java.lang.Math.abs()` branch-free. With this change there is no measurable effect on performance on macOS, but on Linux there is approximatel

Re: [jdk17] RFR: 8269929: (test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output

2021-07-07 Thread Brian Burkhalter
On Wed, 7 Jul 2021 19:05:14 GMT, Roger Riggs wrote: > The test java/lang/ProcessBuilder/Basic.java continues to fail intermittently > with unexpected output from the VM. > It appears that destroying the process causes a vm thread to fail to be > started. > Extend the delay between starting the

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-07-02 Thread Brian Burkhalter
On Fri, 2 Jul 2021 18:43:36 GMT, Joe Wang wrote: >> Both conditions of the statement are intended to be met. If the stream is at >> its end then >> >> if (pos >= count) { >> return -1; >> } >> >> will cause `-1` to be returned because at end of stream the condition

Integrated: 8188046: java.lang.Math.mutliplyHigh does not run in constant time

2021-07-02 Thread Brian Burkhalter
On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter wrote: > Please consider this proposal to remove the fast path in > `java.lang.Math.multiplyHigh()` the small performance improvement of which is > eclipsed by the branch penalty. This pull request has now been integrated. Changeset:

Integrated: 8188044: We need Math.unsignedMultiplyHigh

2021-07-02 Thread Brian Burkhalter
On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter wrote: > Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. This pull request has now been integrated. Changeset: ca4bea46 Author: Brian B

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-07-02 Thread Brian Burkhalter
On Fri, 2 Jul 2021 17:27:34 GMT, Joe Wang wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6766844: Correct error messages in test > > src/java.base/share/classes/java/io/Byte

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-07-02 Thread Brian Burkhalter
On Fri, 2 Jul 2021 16:50:11 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6766844: Correct error messages in test > > test/jdk/java/io/ByteArrayInputStream/ReadA

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-07-02 Thread Brian Burkhalter
> Modify the specification of > `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is > returned instead of `0` when the stream is at its end and the third > parameter, `len`, is zero. Brian Burkhalter has updated the pull request incrementally with on

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]

2021-07-02 Thread Brian Burkhalter
> Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show di

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v3]

2021-07-02 Thread Brian Burkhalter
> Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8188044: Use multiply

Re: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in constant time

2021-07-01 Thread Brian Burkhalter
On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter wrote: > Please consider this proposal to remove the fast path in > `java.lang.Math.multiplyHigh()` the small performance improvement of which is > eclipsed by the branch penalty. Please refer to the issue for a benchmark and samp

RFR: 8188046: java.lang.Math.mutliplyHigh does not run in constant time

2021-07-01 Thread Brian Burkhalter
Please consider this proposal to remove the fast path in `java.lang.Math.multiplyHigh()` the small performance improvement of which is eclipsed by the branch penalty. - Commit messages: - 8188046: java.lang.Math.mutliplyHigh does not run in constant time Changes: https://git.openj

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

2021-07-01 Thread Brian Burkhalter
On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add a method >> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and >> `java.lang.StrictMath`. > > Brian Burkhalter has updated the pull request incrementall

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

2021-07-01 Thread Brian Burkhalter
> Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8188044: Add @see link

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh

2021-06-30 Thread Brian Burkhalter
On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter wrote: > Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. This PR does not address intrinsics for the proposed method; that aspect can be

RFR: 8188044: We need Math.unsignedMultiplyHigh

2021-06-30 Thread Brian Burkhalter
Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`. - Commit messages: - 8188044: We need Math.unsignedMultiplyHigh Changes: https://git.openjdk.java.net/jdk/pull/4644/files Webrev: https://webrevs

Withdrawn: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

2021-06-30 Thread Brian Burkhalter
On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter wrote: > Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and > `read(byte[],int,int)` to return zero per the `InputStream` specification > when the byte array actual or specified length is zero. This pull request has be

[jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

2021-06-30 Thread Brian Burkhalter
Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero. - Commit messages: - 6766844: ByteArrayInputStream#read with a byte array of lengt

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

2021-06-30 Thread Brian Burkhalter
On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter wrote: > Modify the specification of > `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is > returned instead of `0` when the stream is at its end and the third > parameter, `len`, is zero. This PR s

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v5]

2021-06-30 Thread Brian Burkhalter
On Mon, 28 Jun 2021 17:48:37 GMT, Brian Burkhalter wrote: >> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and >> `read(byte[],int,int)` to return zero per the `InputStream` specification >> when the byte array actual or specified length is zero. > > Bria

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v5]

2021-06-29 Thread Brian Burkhalter
On Mon, 28 Jun 2021 17:48:37 GMT, Brian Burkhalter wrote: >> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and >> `read(byte[],int,int)` to return zero per the `InputStream` specification >> when the byte array actual or specified length is zero. > > Bria

Re: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes` system property [v2]

2021-06-28 Thread Brian Burkhalter
On Mon, 28 Jun 2021 18:37:34 GMT, Naoto Sato wrote: >> Please review this small doc change to the system property. Accompanying CSR >> has also been created. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Refined wording.

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v5]

2021-06-28 Thread Brian Burkhalter
> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and > `read(byte[],int,int)` to return zero per the `InputStream` specification > when the byte array actual or specified length is zero. Brian Burkhalter has updated the pull request incrementally with two additional comm

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v4]

2021-06-25 Thread Brian Burkhalter
On Fri, 25 Jun 2021 20:49:16 GMT, Roger Riggs wrote: >> Brian Burkhalter has refreshed the contents of this pull request, and >> previous commits have been removed. The incremental views will show >> differences compared to the previous content of the PR. > > src/java

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v4]

2021-06-25 Thread Brian Burkhalter
> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and > `read(byte[],int,int)` to return zero per the `InputStream` specification > when the byte array actual or specified length is zero. Brian Burkhalter has refreshed the contents of this pull request, and previous com

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v3]

2021-06-25 Thread Brian Burkhalter
> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and > `read(byte[],int,int)` to return zero per the `InputStream` specification > when the byte array actual or specified length is zero. Brian Burkhalter has updated the pull request incrementally with one additional com

Integrated: 4847239: (spec) File.createTempFile() should make it clear that it doesn't create the temporary directory

2021-06-25 Thread Brian Burkhalter
On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter wrote: > Augment the specification of > `java.io.File.createTempFile(String,String,File)` to clarify its behavior > with respect to the `File` parameter `directory`. This pull request has now been integrated. Changeset: 68ef21

Integrated: 6633375: FileOutputStream_md.c should be merged into FileOutputStream.c

2021-06-25 Thread Brian Burkhalter
On Thu, 24 Jun 2021 20:01:27 GMT, Brian Burkhalter wrote: > Merge identical Unix and Windows versions of FileOutputStream_md.c into > single, common FileOutputStream.c. This pull request has now been integrated. Changeset: 3fae4b37 Author: Brian Burkhalter URL:

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-06-25 Thread Brian Burkhalter
On Fri, 25 Jun 2021 17:49:37 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6766844: Add bug ID to test > > The spec for ByteArrayInputStream.read(byte[]

Re: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

2021-06-25 Thread Brian Burkhalter
On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter wrote: >> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and >> `read(byte[],int,int)` to return zero per the `InputStream` specification >> when the byte array actual or specified length is zero. > > Bria

<    1   2   3   4   5   6   7   8   9   10   >