RFR: 8297561: Redundant index check in String.offsetByCodePoints()

2022-11-24 Thread Sergey Tsypanov
`String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one o

Re: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v2]

2022-11-30 Thread Sergey Tsypanov
and rely on the one of > `Character.offsetByCodePoints()`. Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits

Re: RFR: 8297561: Redundant index check in String.offsetByCodePoints()

2022-11-30 Thread Sergey Tsypanov
On Thu, 24 Nov 2022 10:08:31 GMT, Sergey Tsypanov wrote: > `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` > which in turn specifies the same exception thrown under the same conditions > and the implementation does exactly the same checks. This means we c

Re: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v2]

2022-12-01 Thread Sergey Tsypanov
On Wed, 30 Nov 2022 20:41:47 GMT, Claes Redestad wrote: >> Sergey Tsypanov has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contain

Re: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v3]

2022-12-01 Thread Sergey Tsypanov
and rely on the one of > `Character.offsetByCodePoints()`. Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/JDK-8297561' into JDK-8297561 - 8297561: Add copyright and chang

Re: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v4]

2022-12-01 Thread Sergey Tsypanov
and rely on the one of > `Character.offsetByCodePoints()`. Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision: - 8297561: Minor clean-up - 8297561: Fix copyright year - Changes: - all: https://git.openjdk.org/jdk/p

Integrated: 8297561: Redundant index check in String.offsetByCodePoints()

2022-12-01 Thread Sergey Tsypanov
On Thu, 24 Nov 2022 10:08:31 GMT, Sergey Tsypanov wrote: > `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` > which in turn specifies the same exception thrown under the same conditions > and the implementation does exactly the same checks. This means we c

RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check

2022-12-02 Thread Sergey Tsypanov
I found out that this code public class Main { public static void main(String[] args) { String s = "Hello world!"; char[] chars = s.toCharArray(); int point = Character.codePointAt(chars, -1, 1); } } throws `ArrayIndexOutOfBoundsException` instead of JavaDoc-specif

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check

2022-12-02 Thread Sergey Tsypanov
On Fri, 2 Dec 2022 14:47:24 GMT, Roger Riggs wrote: >> I found out that this code >> >> public class Main { >> public static void main(String[] args) { >> String s = "Hello world!"; >> char[] chars = s.toCharArray(); >> int point = Character.codePointAt(chars, -1, 1);

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check

2022-12-02 Thread Sergey Tsypanov
On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov wrote: > I found out that this code > > public class Main { > public static void main(String[] args) { > String s = "Hello world!"; > char[] chars = s.toCharArray(); > int point = Cha

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v2]

2022-12-02 Thread Sergey Tsypanov
t limit) { > if (index >= limit || limit < 0 || limit > a.length) { > throw new IndexOutOfBoundsException(); > } > return codePointAtImpl(a, index, limit); > } > > I suggest to check the `index` parameter explicitly instead of relying on > AIOO

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check

2022-12-02 Thread Sergey Tsypanov
On Fri, 2 Dec 2022 15:32:20 GMT, Brett Okken wrote: > As ArrayIndexOutOfBoundsException is an IndexOutOfBoundsException, it is not > clear to me how this is not matching the javadoc/spec. The check within `codePointAt()` doesn't match the spec. `ArrayIndexOutOfBoundsException` is thrown from t

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v3]

2022-12-02 Thread Sergey Tsypanov
t limit) { > if (index >= limit || limit < 0 || limit > a.length) { > throw new IndexOutOfBoundsException(); > } > return codePointAtImpl(a, index, limit); > } > > I suggest to check the `index` parameter explicitly instead of relying on > AIOO

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v3]

2022-12-03 Thread Sergey Tsypanov
On Fri, 2 Dec 2022 21:31:42 GMT, Roger Riggs wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8298033: Fix test > > test/jdk/java/lang/Character/Supplementary.java line 808: >

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v3]

2022-12-05 Thread Sergey Tsypanov
On Sat, 3 Dec 2022 18:40:59 GMT, Sergey Tsypanov wrote: >> test/jdk/java/lang/Character/Supplementary.java line 808: >> >>> 806: return; >>> 807: } >>> 808: if (expectedException.isInstance(e)) { // >>> Ch

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v4]

2022-12-05 Thread Sergey Tsypanov
t limit) { > if (index >= limit || limit < 0 || limit > a.length) { > throw new IndexOutOfBoundsException(); > } > return codePointAtImpl(a, index, limit); > } > > I suggest to check the `index` parameter explicitly instead of relying on > AIOO

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v5]

2022-12-06 Thread Sergey Tsypanov
t limit) { > if (index >= limit || limit < 0 || limit > a.length) { > throw new IndexOutOfBoundsException(); > } > return codePointAtImpl(a, index, limit); > } > > I suggest to check the `index` parameter explicitly instead of relying on > AIOO

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v6]

2022-12-06 Thread Sergey Tsypanov
t limit) { > if (index >= limit || limit < 0 || limit > a.length) { > throw new IndexOutOfBoundsException(); > } > return codePointAtImpl(a, index, limit); > } > > I suggest to check the `index` parameter explicitly instead of relying on > AIOO

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v5]

2022-12-07 Thread Sergey Tsypanov
On Tue, 6 Dec 2022 16:47:05 GMT, Roger Riggs wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8298033: Fix Character.codePointBefore() > > src/java.base/share/classes/java

Integrated: 8298033: Character.codePoint{At|Before}(char[], int, int) doesn't do JavaDoc-specified check

2022-12-08 Thread Sergey Tsypanov
On Fri, 2 Dec 2022 12:44:18 GMT, Sergey Tsypanov wrote: > I found out that this code > > public class Main { > public static void main(String[] args) { > String s = "Hello world!"; > char[] chars = s.toCharArray(); > int point = Cha

RFR: 8298380: Clean up redundant array length checks in JDK code base

2022-12-08 Thread Sergey Tsypanov
Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like void iterate(T[] items) { if (items.length == 0) { return;

Integrated: 8298380: Clean up redundant array length checks in JDK code base

2022-12-09 Thread Sergey Tsypanov
On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new > [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) > detecting redundant array length check in snip

Re: RFR: 8298380: Clean up redundant array length checks in JDK code base

2022-12-09 Thread Sergey Tsypanov
On Fri, 9 Dec 2022 14:35:47 GMT, Roger Riggs wrote: >> Newer version of IntelliJ IDEA introduces new >> [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) >> detecting redundant array length check in snippets like >>

Re: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile [v2]

2022-12-13 Thread Sergey Tsypanov
On Tue, 13 Dec 2022 09:27:24 GMT, Per Minborg wrote: >> This PR suggests improving performance for read and write operations for the >> longer primitives in `RandomAccessFile`. >> >> These improvements would also propagate to other JDK classes relying on >> these improved `RandomAccessFile` op

Re: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile [v2]

2022-12-13 Thread Sergey Tsypanov
On Tue, 13 Dec 2022 09:27:24 GMT, Per Minborg wrote: >> This PR suggests improving performance for read and write operations for the >> longer primitives in `RandomAccessFile`. >> >> These improvements would also propagate to other JDK classes relying on >> these improved `RandomAccessFile` op

Re: RFR: 8298639: Perform I/O operations in bulk for RandomAccessFile [v2]

2022-12-14 Thread Sergey Tsypanov
On Tue, 13 Dec 2022 19:57:29 GMT, Alan Bateman wrote: > I think that PR was closed as it went inactive Yep, I think there I did everything I could, hope this one will be merged as the changes are helpful - PR: https://git.openjdk.org/jdk/pull/11644

Re: RFR: 8293630: Simplify TreeMap.get() with Comparator.naturalOrder() [v5]

2022-12-22 Thread Sergey Tsypanov
we also change it? Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 

Re: RFR: JDK-8262994: Refactor String.split to help method inlining

2022-12-28 Thread Sergey Tsypanov
On Tue, 27 Dec 2022 20:12:51 GMT, Christian Wimmer wrote: > The method `String.split` contains a fast-path when the regular expression > parameter is not really a regular expression, but just a single split > character. > This fast path vs. slow path check can be constant folded when the regula

Re: RFR: 8299513: Cleanup java.io

2023-01-04 Thread Sergey Tsypanov
On Wed, 4 Jan 2023 15:37:23 GMT, Per Minborg wrote: > Code in java.io contains many legacy constructs and semantics not recommended > including: > > * C-style array declaration > * Unnecessary visibility > * Redundant keywords in interfaces (e.g. public, static) > * Non-standard naming for

RFR: 8299600: Use Objects.check*() where appropriate in java.io

2023-01-04 Thread Sergey Tsypanov
Use the following methods instead of hand-written code: - Objects.checkFromIndexSize() - Objects.checkFromToIndex() - Commit messages: - 8299600: Use Objects.check*() where appropriate in java.io - Merge branch 'master' into index-io - Fix - Check from-to in java.io Changes: http

Re: RFR: 8299600: Use Objects.check*() where appropriate in java.io [v2]

2023-01-05 Thread Sergey Tsypanov
On Thu, 5 Jan 2023 07:11:57 GMT, Alan Bateman wrote: >> Indeed there are at least four regression test failures with this as-is: >> >> - java/io/InputStream/ReadParams.java >> - java/io/OutputStream/WriteParams.java >> - java/io/Writer/WriteParams.java >> - java/nio/channels/FileChannel/Transfer

Re: RFR: 8299600: Use Objects.check*() where appropriate in java.io [v2]

2023-01-05 Thread Sergey Tsypanov
> Use the following methods instead of hand-written code: > - Objects.checkFromIndexSize() > - Objects.checkFromToIndex() Sergey Tsypanov has updated the pull request incrementally with two additional commits since the last revision: - 8299600: Use checkFromIndexSize in PipedWr

Integrated: 8299600: Use Objects.check*() where appropriate in java.io

2023-01-06 Thread Sergey Tsypanov
On Wed, 4 Jan 2023 15:50:35 GMT, Sergey Tsypanov wrote: > Use the following methods instead of hand-written code: > - Objects.checkFromIndexSize() > - Objects.checkFromToIndex() This pull request has now been integrated. Changeset: d086e82b Author: Sergey Tsypanov Committ

Re: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

2023-01-09 Thread Sergey Tsypanov
On Mon, 9 Jan 2023 03:34:55 GMT, Glavo wrote: > `JavaLangAccess::newStringUTF8NoRepl` and > `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They > always copy arrays, rather than avoiding copying as much as possible as > javadoc says. > > I ran the tier1 test without any n

Re: RFR: 8299677: Formatter.format might take a long time to format an integer or floating-point [v4]

2023-01-12 Thread Sergey Tsypanov
On Wed, 11 Jan 2023 19:34:39 GMT, Raffaello Giulietti wrote: >> This change transforms a O(n^2) path to O(n) when prepending zero padding to >> decimal outputs, where n is the length of the padding. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit

Re: RFR: 8299677: Formatter.format might take a long time to format an integer or floating-point [v5]

2023-01-12 Thread Sergey Tsypanov
On Thu, 12 Jan 2023 15:31:03 GMT, Raffaello Giulietti wrote: >> This change transforms a O(n^2) path to O(n) when prepending zero padding to >> decimal outputs, where n is the length of the padding. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit

Re: RFR: 8299807: String.newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

2023-01-16 Thread Sergey Tsypanov
On Mon, 9 Jan 2023 03:34:55 GMT, Glavo wrote: > `JavaLangAccess::newStringUTF8NoRepl` and > `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They > always copy arrays, rather than avoiding copying as much as possible as > javadoc says. > > I ran the tier1 test without any n

RFR: 8300237: Minor improvements in MethodHandles

2023-01-17 Thread Sergey Tsypanov
- `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` when we don't need a copy - comparison of two lists can be done without `Stream.reduce()` - Commit messages: - Fix test - Improve MH Changes: https://git.openjdk.org/jdk/pull/12025/files Webrev: https://w

Re: RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v2]

2023-01-17 Thread Sergey Tsypanov
On Tue, 17 Jan 2023 07:43:07 GMT, Per Minborg wrote: >>> >>> Do you see any concrete examples of classes in the JDK that could benefit >>> from a "VarHandlization"? >> >> `ImageOutputStreamImpl` and `ImageInputStreamImpl` in >> `javax.imageio.stream` have some very similar code that might

Re: RFR: 8300237: Minor improvements in MethodHandles [v2]

2023-01-17 Thread Sergey Tsypanov
> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` > when we don't need a copy > - comparison of two lists can be done without `Stream.reduce()` Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revisio

Re: RFR: 8300237: Minor improvements in MethodHandles [v3]

2023-01-17 Thread Sergey Tsypanov
> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` > when we don't need a copy > - comparison of two lists can be done without `Stream.reduce()` Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision

Re: RFR: 8300237: Minor improvements in MethodHandles [v3]

2023-01-17 Thread Sergey Tsypanov
On Tue, 17 Jan 2023 15:30:12 GMT, Rémi Forax wrote: >> Precious little method handle use in lambda bootstrap since JDK 11. Though I >> agree with the sentiment - having fixed a number of bootstrap issues in the >> past - `MethodHandles` is a small step up the abstraction ladder and the >> code

Re: RFR: 8300237: Minor improvements in MethodHandles [v4]

2023-01-17 Thread Sergey Tsypanov
> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` > when we don't need a copy > - comparison of two lists can be done without `Stream.reduce()` Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision

Re: RFR: 8300237: Minor improvements in MethodHandles [v3]

2023-01-17 Thread Sergey Tsypanov
On Tue, 17 Jan 2023 20:51:06 GMT, Rémi Forax wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Polishing > > src/java.base/share/classes/java/lang/invoke/MethodHandles.

Re: RFR: 8300237: Minor improvements in MethodHandles [v4]

2023-01-17 Thread Sergey Tsypanov
On Tue, 17 Jan 2023 22:28:50 GMT, Claes Redestad wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Merge map() calls > > src/java.base/share/classes/java/lang/invoke/MethodHand

Re: RFR: 8300237: Minor improvements in MethodHandles [v5]

2023-01-18 Thread Sergey Tsypanov
> - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` > when we don't need a copy > - comparison of two lists can be done without `Stream.reduce()` Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last re

Integrated: 8300237: Minor improvements in MethodHandles

2023-01-18 Thread Sergey Tsypanov
On Tue, 17 Jan 2023 08:22:28 GMT, Sergey Tsypanov wrote: > - `MethodType.ptypes()` can be used instead of `MethodType.parameterList()` > when we don't need a copy > - comparison of two lists can be done without `Stream.reduce()` This pull request has now been integrated. Chang

Re: RFR: 8300647: Miscellaneous hashCode improvements in java.base [v2]

2023-01-19 Thread Sergey Tsypanov
On Thu, 19 Jan 2023 13:46:26 GMT, Claes Redestad wrote: >> Went through the jdk and found a few more places where >> `ArraysSupport::vectorizedHashCode` can be used, and a few where adhoc >> methods could be replaced with a plain call to `java.util.Arrays` >> equivalents. This patch addresses

RFR: 8300818: Reduce complexity of padding with DateTimeFormatter

2023-01-21 Thread Sergey Tsypanov
Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like: DateTimeFormatter dtf = new DateTimeFormatterBuilder() .appendLiteral("Date:") .padNext(20, ' ') .append(DateTimeFormatter.ISO_DATE) .toFormatter(); String text = d

Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

2023-01-22 Thread Sergey Tsypanov
d(DateTimeFormatter.ISO_DATE) > .toFormatter(); > String text = dtf.format(LocalDateTime.now()); Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull req

Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

2023-01-22 Thread Sergey Tsypanov
On Sun, 22 Jan 2023 10:56:11 GMT, Claes Redestad wrote: >> Sergey Tsypanov has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request conta

Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

2023-01-22 Thread Sergey Tsypanov
On Sun, 22 Jan 2023 11:36:34 GMT, Claes Redestad wrote: >> Sergey Tsypanov has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request conta

Re: RFR: 8301220: Return value of toArray() of Сollection types from java.base should be trusted

2023-01-27 Thread Sergey Tsypanov
On Thu, 26 Jan 2023 06:46:16 GMT, Glavo wrote: > I checked the `java.base` module, and all the `Collection#toArray()` method > of collections be implemented correctly. > > Their return values can be trusted, so many unnecessary array duplication can > be eliminated. You could also have a look

Re: RFR: 8301220: Return value of toArray() of Сollection types from java.base should be trusted

2023-01-27 Thread Sergey Tsypanov
On Thu, 26 Jan 2023 10:01:21 GMT, Glavo wrote: > it is necessary to copy the elements to a larger new array Right, I missed this is addAll() method. Btw, in this class you could do similar optimization in constructor as well. - PR: https://git.openjdk.org/jdk/pull/12212

Re: RFR: 8301220: Return value of toArray() of Сollection types from java.base should be trusted [v2]

2023-01-27 Thread Sergey Tsypanov
On Fri, 27 Jan 2023 14:28:08 GMT, Alan Bateman wrote: > It might be better to focus on a few specific cases that can be proven to be > safe As of trusted collections from java.base we have - ArrayList - Arrays.asList() - HashSet - LinkedHashSet - TreeSet - EnumSet - ArrayDeque - COWArrayList -

RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey

2023-01-31 Thread Sergey Tsypanov
`ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them. - Commit messages: - Copyright year update - Modernize Bubldes.equals() Changes: https://git.openjdk.org/jdk/pull/12328/files Webrev: https://webrevs.openj

Re: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey

2023-01-31 Thread Sergey Tsypanov
On Tue, 31 Jan 2023 11:40:43 GMT, Sergey Tsypanov wrote: > `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire > outdated. This simple clean-up modernizes them. Btw, in `ResourceBundle.CacheKey.equals()` can we replace Module module = getModule(); Module

Re: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey [v2]

2023-01-31 Thread Sergey Tsypanov
> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire > outdated. This simple clean-up modernizes them. Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: Fix logic - Changes: - all:

Re: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey [v3]

2023-02-01 Thread Sergey Tsypanov
> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire > outdated. This simple clean-up modernizes them. Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: Restore logic - Changes:

Re: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM in ZoneOffset [v4]

2023-02-01 Thread Sergey Tsypanov
On Wed, 1 Feb 2023 13:18:31 GMT, Per Minborg wrote: >> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for >> values in the range [-18h, 18h] for each second that is on an even quarter >> of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a `ConcurrentH

Re: RFR: 8301226: Add clamp() methods to java.lang.Math and to StrictMath [v2]

2023-02-05 Thread Sergey Tsypanov
On Sat, 4 Feb 2023 21:34:50 GMT, Tagir F. Valeev wrote: >> clamp() methods added to Math and StrictMath >> >> `int clamp(long, int, int)` is somewhat different, as it accepts a `long` >> value and safely clamps it to an `int` range. Other overloads work with a >> particular type (long, float a

Re: RFR: 8302163: Speed up various String comparison methods with ArraysSupport.mismatch

2023-02-13 Thread Sergey Tsypanov
On Mon, 13 Feb 2023 09:59:24 GMT, Claes Redestad wrote: > We can improve various String methods such as `startsWith`, `endsWith` and > `regionMatches` by leveraging the intrinsified mismatch methods in > `ArraysSupport`. Looks simple and harmless. - Marked as reviewed by stsypano

Re: RFR: JDK-8301460: Clean up LambdaForm to reference BasicType enums directly

2023-02-14 Thread Sergey Tsypanov
On Mon, 13 Feb 2023 22:05:15 GMT, Mandy Chung wrote: > `LambdaForm` declares int constants for `BasicType::ordinal` to workaround > JDK-8161245. Now these int constants are no longer needed.This removes > these int constants and reference `BasicType` enums directly. src/java.base/share/c

Re: RFR: 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

2023-02-20 Thread Sergey Tsypanov
On Sun, 19 Feb 2023 18:41:18 GMT, liach wrote: > 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not > thread safe Marked as reviewed by stsypanov (Author). - PR: https://git.openjdk.org/jdk/pull/12643

Re: RFR: 8282319: java.util.Locale method to stream available Locales

2023-02-23 Thread Sergey Tsypanov
On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu wrote: > This PR proposes introducing a new method to Locale which returns > Stream > > It involves adding an additional method to _LocaleServiceProviderPool_ that > returns Stream, which _Locale_ can call. > > `LocaleServiceProviderPool.streamAllAv

Re: RFR: 8282319: java.util.Locale method to stream available Locales

2023-02-23 Thread Sergey Tsypanov
On Fri, 27 Jan 2023 21:48:26 GMT, Justin Lu wrote: > This PR adds a new method to java.util.Locale which returns Stream > > The contents of the Stream are composed of the same underlying elements as > Locale.getAvailableLocales(). > > This method allows streaming of the Locale array without cr

Re: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey [v3]

2023-03-01 Thread Sergey Tsypanov
On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov wrote: >> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire >> outdated. This simple clean-up modernizes them. > > Sergey Tsypanov has updated the pull request incrementally with one > additional

Re: RFR: JDK-8302323 Add repeat methods to StringBuilder/StringBuffer [v8]

2023-03-14 Thread Sergey Tsypanov
On Fri, 3 Mar 2023 19:04:22 GMT, Jim Laskey wrote: >> Add the ability to repeatedly append char and CharSequence data to >> StringBuilder/StringBuffer. > > Jim Laskey has updated the pull request incrementally with one additional > commit since the last revision: > > Expand test for StringBu

Re: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test

2023-03-15 Thread Sergey Tsypanov
On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos wrote: > By avoiding a bit shift operation for the latin1 fast-path test, we can speed > up the `java.lang.CharacterData.of` method by ~25% for latin1 code points. > > The latin1 test is currently implemented as `ch >>> 8 == 0`. We can replace

Re: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test

2023-03-15 Thread Sergey Tsypanov
On Wed, 15 Mar 2023 11:58:14 GMT, Claes Redestad wrote: >> By avoiding a bit shift operation for the latin1 fast-path test, we can >> speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code >> points. >> >> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can r

Re: RFR: 8304245: Speed up CharacterData.of by avoiding bit shifting in the latin1 fast-path test [v2]

2023-03-15 Thread Sergey Tsypanov
On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos wrote: >> By avoiding a bit shift operation for the latin1 fast-path test, we can >> speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code >> points. >> >> The latin1 test is currently implemented as `ch >>> 8 == 0`. We can r

Re: RFR: 8300979: Lazily initialize (byte, char)arr in java.io.DataInputStream

2023-03-21 Thread Sergey Tsypanov
On Tue, 21 Mar 2023 15:41:13 GMT, Per Minborg wrote: > This PR proposed to lazily initialize the scratch arrays only if/when needed. Nice idea. Just wonder could we do the same for `BufferedInputStream`? - PR Comment: https://git.openjdk.org/jdk/pull/13121#issuecomment-1478546070

RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream

2023-03-23 Thread Sergey Tsypanov
By default `BufferedInputStream` is constructed with internal buffer with capacity 8192. In some cases this buffer is never used, e.g. when we call `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when `BufferedInputStream` is cascaded. - Commit messages: - 8

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream

2023-03-23 Thread Sergey Tsypanov
On Thu, 23 Mar 2023 15:18:54 GMT, Chen Liang wrote: >> But it's just comment clean up > > No? The one above is API specification (Javadoc); the one below is comments. Right, I'll revert it - PR Review Comment: https://git.openjdk.org/jdk/pull/13150#discussion_r1146370513

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream

2023-03-23 Thread Sergey Tsypanov
On Wed, 22 Mar 2023 23:01:32 GMT, Chen Liang wrote: > This change exposes the CLOSED array Otherwise we have to either call `getInIfOpen()`/`getBufIfOpen` making them at least protected or dodge this somehow via `SharedSecrets` > I mean that additional API exposure is acceptable and backward c

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream

2023-03-23 Thread Sergey Tsypanov
On Thu, 23 Mar 2023 14:51:40 GMT, Sergey Tsypanov wrote: >> src/java.base/share/classes/java/io/BufferedInputStream.java line 211: >> >>> 209: throw new IllegalArgumentException("Buffer size <= 0"); >>> 210: } >>> 211:

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v2]

2023-03-23 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v2]

2023-03-23 Thread Sergey Tsypanov
On Thu, 23 Mar 2023 19:55:04 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/BufferedInputStream.java line 183: >> >>> 181: if (buffer == EMPTY) { >>> 182: buf = buffer = new byte[size]; >>> 183: } >> >> You should probably use compareAndSet here too

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v2]

2023-03-23 Thread Sergey Tsypanov
On Thu, 23 Mar 2023 19:48:40 GMT, Eirik Bjorsnos wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update src/java.base/share/classes/java/io/BufferedInputStream.java >> >>

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v3]

2023-03-23 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v4]

2023-03-24 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v3]

2023-03-24 Thread Sergey Tsypanov
On Fri, 24 Mar 2023 10:27:45 GMT, Alan Bateman wrote: > This will ensure that read, skip, reset, etc. check buf as before Why do we so heavily rely on `buf` if we can do open/close check with `getInIfOpen()`? - PR Comment: https://git.openjdk.org/jdk/pull/13150#issuecomment-148266

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v5]

2023-03-24 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v2]

2023-03-24 Thread Sergey Tsypanov
On Thu, 23 Mar 2023 21:15:44 GMT, Eirik Bjorsnos wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update src/java.base/share/classes/java/io/BufferedInputStream.java >> >>

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v5]

2023-03-24 Thread Sergey Tsypanov
On Fri, 24 Mar 2023 16:12:13 GMT, Chen Liang wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8304745: Add benchmark > > test/micro/org/openjdk/bench/java/io/BufferedInputStream

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v6]

2023-03-24 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v7]

2023-03-24 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v6]

2023-03-24 Thread Sergey Tsypanov
On Fri, 24 Mar 2023 17:59:24 GMT, Chen Liang wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8304745: Amend copyright > > test/micro/org/openjdk/bench/java/io/BufferedInputStream

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v8]

2023-03-24 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

2023-03-24 Thread Sergey Tsypanov
On Mon, 13 Mar 2023 19:24:38 GMT, Roger Riggs wrote: >> Sergey Tsypanov has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request conta

Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

2023-03-24 Thread Sergey Tsypanov
On Mon, 23 Jan 2023 11:34:27 GMT, Claes Redestad wrote: >> The modified code is called only when a user explicitly calls `padNext(int, >> char)`, i.e. if I modified the example snippet as >> >> DateTimeFormatter dtf = new DateTimeFormatterBuilder() >> .appendLiteral("Date:") >> //.padNext(20,

Re: RFR: 8300818: Reduce complexity of padding with DateTimeFormatter [v2]

2023-03-24 Thread Sergey Tsypanov
On Sun, 22 Jan 2023 09:50:21 GMT, Sergey Tsypanov wrote: >> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This >> can be reduced to O(1) improving the code like: >> >> DateTimeFormatter dtf = new DateTimeFormatterBuilder() >> .appe

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v8]

2023-03-27 Thread Sergey Tsypanov
On Fri, 24 Mar 2023 19:30:22 GMT, Sergey Tsypanov wrote: >> By default `BufferedInputStream` is constructed with internal buffer with >> capacity 8192. In some cases this buffer is never used, e.g. when we call >> `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS

Re: RFR: 8304745: Lazily initialize byte[] in java.io.BufferedInputStream [v9]

2023-03-27 Thread Sergey Tsypanov
> By default `BufferedInputStream` is constructed with internal buffer with > capacity 8192. In some cases this buffer is never used, e.g. when we call > `IS.readNBytes()` or `IS.readAllBytes()` (relying on `BIS.read1()`) or when > `BufferedInputStream` is cascaded. Sergey Tsypanov

Re: RFR: 8304918: Remove unused decl field from AnnotatedType implementations

2023-03-27 Thread Sergey Tsypanov
On Sat, 25 Mar 2023 05:52:44 GMT, Chen Liang wrote: > In `AnnotatedTypeBaseImpl`, a `decl` field is declared, referring to the > declaration that the AnnotatedType is from. However, this field is not used > anywhere except passing to constructors of other implementations; it's not > used in de

RFR: 8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()

2023-03-27 Thread Sergey Tsypanov
1) When `DateTimeFormatter` is reused we don't need to copy `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken from cache. In the related benchmark allocation of `HashSet` takes ~93% of all time, so avoiding it should bring some improvement for cases when we reuse `DateTim

Re: RFR: 8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree()

2023-03-27 Thread Sergey Tsypanov
On Fri, 17 Feb 2023 09:50:16 GMT, Sergey Tsypanov wrote: > 1) When `DateTimeFormatter` is reused we don't need to copy > `availableZoneIds` and allocate `nonRegionIds` as PrefixTree can be taken > from cache. In the related benchmark allocation of `HashSet` takes ~93% of

Re: RFR: 8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]

2023-03-29 Thread Sergey Tsypanov
On Tue, 28 Mar 2023 16:40:17 GMT, Naoto Sato wrote: >> Sergey Tsypanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8304745: Fix package > > test/micro/org/openjdk/bench/java/time/format/ZonedDateTimeF

Re: RFR: 8304976: Optimize DateTimeFormatterBuilder.ZoneTextPrinterParser.getTree() [v2]

2023-03-29 Thread Sergey Tsypanov
dPattern(":MM:dd:HH:mm:v").toFormatter(); > private static final String TEXT = "2015:03:10:12:13:ECT"; > > @Setup > public void setUp() { > ZonedDateTime.parse(TEXT, df); > } > > @Benchmark > public ZonedDateTime p

Re: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey [v3]

2023-03-29 Thread Sergey Tsypanov
On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov wrote: >> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire >> outdated. This simple clean-up modernizes them. > > Sergey Tsypanov has updated the pull request incrementally with one > additional

  1   2   3   >