Integrated: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown

On Sat, 29 Jan 2022 16:31:43 GMT, Tagir F. Valeev wrote: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and > report artificial estimatedSize(), much bigger than the real one. This will > allow Abst

Re: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v5]

On Thu, 10 Feb 2022 04:30:34 GMT, Tagir F. Valeev wrote: >> See the bug description for details. >> >> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED >> and report artificial estimatedSize(), much bigger than the real one. This >>

Re: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v4]

On Thu, 10 Feb 2022 03:22:42 GMT, Tagir F. Valeev wrote: >> See the bug description for details. >> >> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED >> and report artificial estimatedSize(), much bigger than the real one. This >>

Re: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v5]

tra field in ArraySpliterator which increases a > footprint by 8 bytes. > > I added a simple test using an artificial collector to ensure that at least > two non-empty parts are created when parallelizing Stream.iterate source. > More testing ideas are welcome. Tagir F. Valeev ha

Re: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v4]

tra field in ArraySpliterator which increases a > footprint by 8 bytes. > > I added a simple test using an artificial collector to ensure that at least > two non-empty parts are created when parallelizing Stream.iterate source. > More testing ideas are welcome. Tagir F. Valeev ha

Re: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v3]

tra field in ArraySpliterator which increases a > footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used > when parallelizing Stream.iterate source. More testing ideas are welcome. Tagir F. Valeev has updated the pull request incremen

Re: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v2]

tra field in ArraySpliterator which increases a > footprint by 8 bytes. > > I added a simple test to ensure that at least two threads are actually used > when parallelizing Stream.iterate source. More testing ideas are welcome. Tagir F. Valeev has updated the pull request incremen

RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown

See the bug description for details. I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to

Withdrawn: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > Currently, when the stream holds a resource, it's necessary to wrap it with > try-with-resources. This undermines the compact and fluent style of stream > API calls. For example, if we want to get the `List` of fil

Re: RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

On Sun, 3 Oct 2021 11:00:25 GMT, Tagir F. Valeev wrote: > Currently, when the stream holds a resource, it's necessary to wrap it with > try-with-resources. This undermines the compact and fluent style of stream > API calls. For example, if we want to get the `List` of fil

RFR: 8274412: Add a method to Stream API to consume and close the stream without using try-with-resources

Currently, when the stream holds a resource, it's necessary to wrap it with try-with-resources. This undermines the compact and fluent style of stream API calls. For example, if we want to get the `List` of files inside the directory and timely close the underlying filehandle, we should use

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

On Mon, 12 Jul 2021 17:59:32 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 refreshed the contents of this pull request, and > previous commits have been removed. The

Re: RFR: 8272137: Make Collection and Optional classes streamable

On Mon, 9 Aug 2021 12:28:23 GMT, CC007 wrote: > create Streamable and ParallelStreamable interface and use them in Collection > and Optional Mostly agreed with Brian. Judging from 7 years of using Stream API, I can say that this abstraction would not solve any real problem. If you need a way

Re: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method [v5]

On Mon, 28 Jun 2021 19:45:34 GMT, Roger Riggs wrote: >> Add java.util.Objects.newIdentity to supply a unique object with identity. >> This is a replacement code can be used today for the traditional new >> Object() idiom, which will be deprecated under Project Valhalla. >> Refer to [JEP 401:

Integrated: 8267587: Update java.util to use enhanced switch

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote: > Inspired by PR#4088. Most of the changes are done automatically using > IntelliJ IDEA refactoring. Some manual adjustments are also performed, > including indentations, moving comments, extracting common cast out

Re: RFR: 8267587: Update java.util to use enhanced switch [v6]

On Thu, 27 May 2021 13:47:16 GMT, Daniel Fuchs wrote: >> Tagir F. Valeev 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: 8267587: Update java.util to use enhanced switch [v7]

hat there are some switches having one branch only in > JapaneseImperialCalendar.java. Probably it would be better to replace them > with `if` statement? Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commi

Integrated: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)

On Sat, 10 Apr 2021 06:30:33 GMT, Tagir F. Valeev wrote: > With the introduction of `toList()`, preserving the SIZED characteristics in > more cases becomes more important. This patch preserves SIZED on `skip()` and > `limit()` operations, so now every combination of > `map/

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v9]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 3

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v8]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 th

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v7]

On Mon, 24 May 2021 19:51:04 GMT, Paul Sandoz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Trailing whitespace removed > > src/java.base/share/classes/java/util/stream/

Re: RFR: 8267587: Update java.util to use enhanced switch [v6]

On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using >> IntelliJ IDEA refactoring. Some manual adjustments are also performed, >> including indentations, moving comments, extracting common cast

Re: RFR: 8267587: Update java.util to use enhanced switch [v5]

On Tue, 25 May 2021 16:52:06 GMT, Brian Goetz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/JapaneseI

Re: RFR: 8267587: Update java.util to use enhanced switch [v6]

hat there are some switches having one branch only in > JapaneseImperialCalendar.java. Probably it would be better to replace them > with `if` statement? Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: - JapaneseImpe

Re: RFR: 8267587: Update java.util to use enhanced switch [v5]

On Tue, 25 May 2021 16:47:15 GMT, Brian Goetz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/Calen

Re: RFR: 8267587: Update java.util to use enhanced switch [v5]

On Tue, 25 May 2021 15:51:38 GMT, Chris Hegarty wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> More vertical alignment > > src/java.base/share/classes/java/util/Calen

Integrated: 8267452: Delegate forEachRemaining in Spliterators.iterator()

On Thu, 20 May 2021 10:16:28 GMT, Tagir F. Valeev wrote: > Sometimes, `Spliterator::forEachRemaining` has much more optimized > implementation, compared to `Spliterator::tryAdvance`. For example, if a > `Stream::spliterator` called for a stream that has intermediate operations, >

Re: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v3]

; `IteratorFromSpliteratorTest` to cover these scenarios. I checked that > removing `valueReady = false;` or `action.accept(t);` lines from newly > implemented `forEachRemaining` method causes new tests to fail (but old tests > don't fail due to this). Tagir F. Valeev has updated the pul

Re: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v2]

On Tue, 25 May 2021 15:49:55 GMT, Paul Sandoz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Test: formatting; tests for empty spliterator > > Oops i missed the bit about test

Re: RFR: 8267587: Update java.util to use enhanced switch [v5]

hat there are some switches having one branch only in > JapaneseImperialCalendar.java. Probably it would be better to replace them > with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: More vertical alignment

Re: RFR: 8267587: Update java.util to use enhanced switch [v3]

On Tue, 25 May 2021 10:31:33 GMT, Patrick Concannon wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Indent some lines to make GitHub diff happier > > src/jav

Re: RFR: 8267587: Update java.util to use enhanced switch [v4]

hat there are some switches having one branch only in > JapaneseImperialCalendar.java. Probably it would be better to replace them > with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Vertical alignment for

Re: RFR: 8267587: Update java.util to use enhanced switch [v3]

On Tue, 25 May 2021 03:48:41 GMT, Tagir F. Valeev wrote: >> src/java.base/share/classes/java/util/regex/CharPredicates.java line 217: >> >>> 215: case "WORD" -> WORD(); >>> 216: default -> null; >>> 217: }; &

Re: RFR: 8267587: Update java.util to use enhanced switch [v3]

hat there are some switches having one branch only in > JapaneseImperialCalendar.java. Probably it would be better to replace them > with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Indent some lines to

Re: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v2]

On Mon, 24 May 2021 16:35:08 GMT, Paul Sandoz wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Test: formatting; tests for empty spliterator > > Changes look good. > >

Re: RFR: 8267587: Update java.util to use enhanced switch [v2]

hat there are some switches having one branch only in > JapaneseImperialCalendar.java. Probably it would be better to replace them > with `if` statement? Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Unindent switch case

Re: RFR: 8267587: Update java.util to use enhanced switch

On Mon, 24 May 2021 13:46:58 GMT, Daniel Fuchs wrote: >> Inspired by PR#4088. Most of the changes are done automatically using >> IntelliJ IDEA refactoring. Some manual adjustments are also performed, >> including indentations, moving comments, extracting common cast out of >> switch

Re: RFR: 8267587: Update java.util to use enhanced switch

On Mon, 24 May 2021 13:44:36 GMT, Daniel Fuchs wrote: >> Inspired by PR#4088. Most of the changes are done automatically using >> IntelliJ IDEA refactoring. Some manual adjustments are also performed, >> including indentations, moving comments, extracting common cast out of >> switch

Re: RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator() [v2]

; `IteratorFromSpliteratorTest` to cover these scenarios. I checked that > removing `valueReady = false;` or `action.accept(t);` lines from newly > implemented `forEachRemaining` method causes new tests to fail (but old tests > don't fail due to this). Tagir F. Valeev has updated the pull r

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v7]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30

RFR: 8267587: Update java.util to use enhanced switch

Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc. I also noticed that there are some switches

Re: RFR: 8267587: Update java.util to use enhanced switch

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev wrote: > Inspired by PR#4088. Most of the changes are done automatically using > IntelliJ IDEA refactoring. Some manual adjustments are also performed, > including indentations, moving comments, extracting common cast out

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v6]

On Sun, 23 May 2021 11:24:12 GMT, Tagir F. Valeev wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of &g

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v3]

On Mon, 17 May 2021 22:08:01 GMT, Paul Sandoz wrote: >> I see your concern. I made some additional benchmarks and added them here. >> First, CountSized, which just gets the stream size without actual traversal. >> We can see how the performance changes depending on number of stream >>

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v6]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 th

RFR: 8267452: Delegate forEachRemaining in Spliterators.iterator()

Sometimes, `Spliterator::forEachRemaining` has much more optimized implementation, compared to `Spliterator::tryAdvance`. For example, if a `Stream::spliterator` called for a stream that has intermediate operations, `tryAdvance()` may buffer intermediate elements while `forEachRemaining()` just

Integrated: 8265356: need code example for getting canonical constructor of a Record

On Sat, 17 Apr 2021 08:55:59 GMT, Tagir F. Valeev wrote: > I decided to show a complete static method in the example, so it could be > copied to user utility class as is. Not sure if it's reasonable to add > `assert cls.isRecord();` there. Also I don't know whether there's a >

Re: RFR: 8265356: need code example for getting canonical constructor of a Record [v2]

On Sat, 24 Apr 2021 01:32:45 GMT, Tagir F. Valeev wrote: >> I decided to show a complete static method in the example, so it could be >> copied to user utility class as is. Not sure if it's reasonable to add >> `assert cls.isRecord();` there. Also I don't know whether there'

Re: RFR: 8265356: need code example for getting canonical constructor of a Record [v3]

laredAnnotations, > // Value of classRedefinedCount when we created this AnnotationData > instance > int redefinedCount) { > } > > > Please tell me if it's ok to fix 1 and 2 along with this PR. Tagir F. Valeev has updated the pull request incrementally with one

Re: RFR: 8265356: need code example for getting canonical constructor of a Record

On Tue, 20 Apr 2021 17:42:27 GMT, Stuart Marks wrote: >> I decided to show a complete static method in the example, so it could be >> copied to user utility class as is. Not sure if it's reasonable to add >> `assert cls.isRecord();` there. Also I don't know whether there's a >> limitation on

Re: RFR: 8265356: need code example for getting canonical constructor of a Record [v2]

laredAnnotations, > // Value of classRedefinedCount when we created this AnnotationData > instance > int redefinedCount) { > } > > > Please tell me if it's ok to fix 1 and 2 along with this PR. Tagir F. Valeev has updated the pull request incrementally with three

Re: RFR: 8265237: String.join and StringJoiner can be improved further [v2]

On Thu, 15 Apr 2021 19:26:48 GMT, Peter Levart wrote: >> While JDK-8148937 improved StringJoiner class by replacing internal use of >> getChars that copies out characters from String elements into a char[] array >> with StringBuilder which is somehow more optimal, the improvement was >>

RFR: 8265356: need code example for getting canonical constructor of a Record

I decided to show a complete static method in the example, so it could be copied to user utility class as is. Not sure if it's reasonable to add `assert cls.isRecord();` there. Also I don't know whether there's a limitation on max characters in the sample code. Probable a line break in `static

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v5]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v4]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 3

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v3]

On Sat, 17 Apr 2021 01:55:26 GMT, Tagir F. Valeev wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of &g

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v3]

Limit 1 thrpt 30 17980,750 ± 2329,077 > ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 180

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v2]

> ops/s > value.SliceToArray.seq_baseline1 thrpt 30 66512,898 ± 1001,042 > ops/s > value.SliceToArray.seq_limit 1 thrpt 30 41792,549 ± 1085,547 > ops/s > value.SliceToArray.seq_skipLimit 1 thrpt 30 18007,613 ± 141,716 > ops/s > > I

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit) [v2]

On Sat, 10 Apr 2021 14:18:57 GMT, Vladimir Sitnikov wrote: >> Tagir F. Valeev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fixes according to review: >> >> 1. Comments in adjustSize &

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)

On Sat, 10 Apr 2021 14:16:40 GMT, Vladimir Sitnikov wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of >>

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)

On Sat, 10 Apr 2021 14:13:55 GMT, Vladimir Sitnikov wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of >>

Re: RFR: 8265029: Preserve SIZED characteristics on slice operations (skip, limit)

On Sat, 10 Apr 2021 14:10:21 GMT, Vladimir Sitnikov wrote: >> With the introduction of `toList()`, preserving the SIZED characteristics in >> more cases becomes more important. This patch preserves SIZED on `skip()` >> and `limit()` operations, so now every combination of >>

RFR: JDK-8265029: Preserve SIZED characteristics on slice operations (skip, limit)

With the introduction of `toList()`, preserving the SIZED characteristics in more cases becomes more important. This patch preserves SIZED on `skip()` and `limit()` operations, so now every combination of `map/mapToX/boxed/asXyzStream/skip/limit/sorted` preserves size, and `toList()`,

Re: RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices

On Fri, 19 Mar 2021 14:34:00 GMT, Rafael Winterhalter wrote: >> A general comment, the enum constructor situation is a bit tricky as >> >> 1) There is no 100% reliable way to determine which of a enum constructor's >> args are synthetic. >> >> 2) How a Java compiler generates enum

Integrated: 8259622: TreeMap.computeIfAbsent deviates from spec

On Wed, 13 Jan 2021 09:51:01 GMT, Tagir F. Valeev wrote: > Handle TreeMap::computeIfAbsent when previous mapping with null value existed > (in this case spec requires to overwrite the existing mapping) This pull request has now been integrated. Changeset: 2c8e337d Author: Tagir F.

Re: RFR: 8259622: TreeMap.computeIfAbsent deviates from spec [v2]

> Handle TreeMap::computeIfAbsent when previous mapping with null value existed > (in this case spec requires to overwrite the existing mapping) Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Copyright year u

RFR: 8259622: TreeMap.computeIfAbsent deviates from spec

Handle TreeMap::computeIfAbsent when previous mapping with null value existed (in this case spec requires to overwrite the existing mapping) - Commit messages: - 8259622: TreeMap.computeIfAbsent deviates from spec Changes: https://git.openjdk.java.net/jdk/pull/2058/files Webrev:

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 28 Oct 2020 15:56:48 GMT, Alan Bateman wrote: >> Kim Barrett has updated the pull request incrementally with one additional >> commit since the last revision: >> >> improve wording in refersTo javadoc > > The API looks good, thanks for getting this in. Hello! As an IDE developer,

Re: RFR: 8180352: Add Stream.toList() method

On Wed, 4 Nov 2020 08:50:49 GMT, Zheka Kozlov wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Tue, 13 Oct 2020 19:51:30 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified

Re: JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap

Hello! Great and long-awaited feature, thanks! I don't see that modCount is checked after calling mappingFunction in compute/computeIfAbsent/computeIfPresent. Is it possible to break the Map if mappingFunction changes the Map content? See similar problems in HashMap:

Re: 8072784: Better spliterator implementation for BitSet.stream()

Hello! Is it necessary to report SIZED characteristic and calculate the cardinality in advance making two-pass traversal? This improves bitSet.stream().toArray() performance (also bitSet.stream().count(), but it's rare case in practice). However this is just waste of time for any other stream

Re: 8168841 The JavaDoc of java.util.stream.Collectors method collectingAndThen has incorrect code snippet

Looks good. PS> Hi, PS> Please review the following JavDoc fix for PS> j.u.stream.Collectors:: collectingAndThen. PS> Thanks, PS> Paul. PS> diff -r 2e076c7e72d6 PS> src/java.base/share/classes/java/util/stream/Collectors.java PS> --- PS>

Re: Make iterators cloneable?

Hello! As your keys are comparable, you can create normal iterators and filter the results like this: for(String v1 : s) { for(String v2 : s) { if(v1.compareTo(v2) < 0) { System.out.println(v1 + " <-->" + v2); } } } Or using Stream API: s.stream().flatMap(v1 -> s.stream()

Re: Exceptional behavior of parallel stream

Hello, Doug! Thank you for your response. DL> In your example, you can witness the delayed termination of other threads DL> upon exception in another because you add side-effecting operations DL> (here, just printing). Avoiding all this would force sequential processing. DL> But if the supplied

Exceptional behavior of parallel stream

Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the caller as is), the behavior for parallel streams

Re: Collectors.toSet() small performance improvement

PS> Paul. >> On 8 Aug 2016, at 22:31, Tagir F. Valeev <amae...@gmail.com> wrote: >> >> Hello! >> >> I'd like to propose a simple performance patch for Collectors.toSet(): >> >> --- a/src/java.base/share/classes/java/util/stream/Collecto

Re: Collectors.toSet() small performance improvement

Hello, Aleksey! Thank you for review. AS> Good trick, but does it work properly with the sets that care about the AS> add order, e.g. LinkedHashSet? I guess our saving grace here is AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter AS> order without violating the API

Collectors.toSet() small performance improvement

Hello! I'd like to propose a simple performance patch for Collectors.toSet(): --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 @@ -295,7

Re: RFR: Implement RandomAccess spliterator

Hello! (disclaimer: I'm not an official reviewer) > ((AbstractList) lst).modCount; Raw-type casts should be replaced with AbstractList to avoid warning. > public RandomAccessSpliterator trySplit() Covariant return type seems to be unnecessary here as this spliterator is not public and

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Hello! Thank you for comments. Update: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r3/ AS> Test: AS> *) Formatting: "i=0", "i *) Formatting: "} catch (NSEE ex)" should be on the same line; Done. AS> *) What does the "for (int i=0;

Re: RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Thank you for reviews! Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r2/ AS> *) Does EA break if you make ArrayItr inner class to gain the access to AS> E[] a? No, I checked, it still allocates. AS> *) next(): Missing braces in throw new NSEE() block; Fixed AS>

RFR: 8155600 - Performance optimization of Arrays.asList().iterator()

Hello! Please review and sponsor the following patch: https://bugs.openjdk.java.net/browse/JDK-8155600 http://cr.openjdk.java.net/~tvaleev/webrev/8155600/r1/ It appears that custom implementation of Arrays.asList().iterator() is noticeably more performant than the AbstractList implementation

Re: RFR(m): 8140281 deprecate Optional.get()

Hello! While I'm not a reviewer, I agree with Stephen. While I understand the rationale, such renaming would cause even more confusion and pain. Also I think this is not the worst part of Java API, so if we start to rename things, where should we stop then? With best regards, Tagir Valeev.

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! PS> Thinking some more about this, i think it would be preferable. It PS> reduces the explicit referral to PS> ForkJoinPool.getCommonPoolParallelism(). No problems, here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r2/ All tests pass. With best regards, Tagir

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! webrev is updated in-place (just added parentheses): http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ Updated benchmark source and results are available here: http://cr.openjdk.java.net/~tvaleev/webrev/8154387/jmh/ In general I observe that for low-Q filter (x -> true) the results

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! Thank you for review! PS> 913 UnorderedSliceSpliterator(T_SPLITR s, long skip, long limit) { PS> 914 this.s = s; PS> 915 this.unlimited = limit < 0; PS> 916 this.skipThreshold = limit >= 0 ? limit : 0; PS> 917 this.chunkSize =

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

t for limit = 2000 the performance is the same as I have 4 CPU machine and 2000 is greater than 128*4. On the other hand, 200 is less than 128*4, so this case is also improved (though not so drastically as less limits). With best regards, Tagir Valeev. SZ> Regards, SZ> Stefan SZ> 2016-04-16 15:0

RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hello! Please review and sponsor the following patch: https://bugs.openjdk.java.net/browse/JDK-8154387 http://cr.openjdk.java.net/~tvaleev/webrev/8154387/r1/ The rationale is to speed-up the parallel processing for unordered streams with low limit value. Such problems occur when you want to

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

lse(LongStreams.of(1, 10).boxed().spliterator() SZ> .hasCharacteristics(Spliterator.SORTED)); SZ> The asserts for IntStreams.range(1, 10).asDoubleStream() would have SZ> to be changed to account for DISTINCTness, of course. SZ> Regards, SZ> Stefan SZ> 2016-0

Re: Expecting Integer.valueOf(String) to accept Literal format ...

Strictly speaking there are many more ways to specify integer constant in Java. Like int x = 045; int x = 0x34; int x = 0b11101; So why should we support "4_5_6" only, but not "0x456"? Note that "045" is already parsed by Integer.valueOf, but as decimal number, not as octal. Thus I don't think

RFR: 8153332 - Stream API: Fuse sorted().limit(n) into single operation

Hello! Please review the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8153332 http://cr.openjdk.java.net/~tvaleev/webrev/8153332/r1/ It was earlier discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039308.html The motivation and algorithm are

RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hello! Please review and sponsor the following patch: http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ The patch preserves more characteristics on primitive stream operations: IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT IntStream.asLongStream() preserves SORTED

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Looks good for me, thank you! With best regards, Tagir Valeev. >> I think they are important, more so the test update. >> >> If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan >> are you ok with that? >> IG> Sure! IG> Here's the webrev, updated with those changes: IG>

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

07/webrev/ >> >> The fix was built/tested successfully on all supported platforms. >> >> Sincerely yours, >> Ivan >> >> On 02.02.2016 9:55, Martin Buchholz wrote: >>> On Mon, Feb 1, 2016 at 10:19 PM, Tagir F. Valeev <amae...@gmail.com>

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

== point)) { PL> end = true; PL> } else if (point == 0) { PL> point = roll; PL> } PL> } PL> return !end; PL> } PL> }.stream().forEach

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

ng int values from a Scanner into an IntStream, until SM>>> there are no more, leaving the scanner at a known state. Suppose there were an SM>>> iterate(Supplier) overload. Then something like this would work: SM>>> Scanner sc = new Scanner("1 2 3 4 foo"

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

() -> sc.hasNextInt() ? OptionalInt.of(sc.nextInt()) SM>>: OptionalInt.empty()) SM>> .forEach(System.out::println); SM>> assert sc.hasNext(); SM>> System.out.println(sc.next()); // prints "foo" SM>&

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

that the termination condition is SM> separate from the values that go into the stream. In particular there's no SM> "seed" value to which a termination condition can be applied. (And "iterate" SM> might not be the best name for this method, either.) SM> Oh well, I thin

Re: Stream API: Fuse sorted().limit(n) into single operation

eliminates allocation of PL> temporary array for merging for the cost of pre-merge step PL> which just derives the end indices. There's a chance that this PL> might improve performance because it trades memory writes for reads. PL> What do you think? PL> Reg

  1   2   >