On Fri, 31 May 2024 14:24:56 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2024:
>>
>>> 2022: }
>>> 2023: if (pb == (pb = b)) // base
>>> unchanged
>>> 2024:
On Fri, 31 May 2024 13:18:33 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 31 May 2024 13:18:33 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 22 May 2024 07:56:26 GMT, Alan Bateman wrote:
>>> @bchristi-git Just checking in—we're waiting for CSR-approval here before
>>> integrating? 樂
>>
>> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer
>> ✔️s.
>
>> Indeed - can't move forward without a CSR.
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 22 May 2024 15:32:42 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 22 May 2024 15:32:42 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 22 May 2024 15:32:42 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Wed, 17 Apr 2024 17:12:28 GMT, Brent Christian wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Another update to reachabilityFence() @apiNote
>
> AFAICT, all review feedback on this change has been
On Thu, 16 May 2024 21:36:03 GMT, Konstantin Nisht wrote:
>> @AlanBateman @DougLea Reviews are most welcome :)
>
> @viktorklang-ora We managed to reproduce it quite reliably by running the
> test from the bug report multiple times (in our case, it was 100). I
> understand this does not make a
On Thu, 16 May 2024 14:54:52 GMT, Viktor Klang wrote:
> Local testing seems to indicate that this fix (which mirrors what's done in
> the FIFO mode) addresses the problem. Regression test added for JDK20+
This pull request has now been integrated.
Changeset: b78613b6
Author:Viktor
> Local testing seems to indicate that this fix (which mirrors what's done in
> the FIFO mode) addresses the problem. Regression test added for JDK20+
Viktor Klang has updated the pull request incrementally with one additional
commit since the last revision:
Turn the Runnables into cal
On Mon, 20 May 2024 14:49:13 GMT, Alan Bateman wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Moving the memory leak test for SynchronousQueue into its own test and
>> runs only fo
> Local testing seems to indicate that this fix (which mirrors what's done in
> the FIFO mode) addresses the problem. Regression test added for JDK20+
Viktor Klang has updated the pull request incrementally with one additional
commit since the last revision:
Addressing review fe
On Fri, 17 May 2024 13:49:44 GMT, Doug Lea wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Moving the memory leak test for SynchronousQueue into its own test and
>> runs only fo
> Local testing seems to indicate that this fix (which mirrors what's done in
> the FIFO mode) addresses the problem.
>
> But with that said, I haven't come up with a decent way of adding some form
> of regression test. Suggestions are most welcome. /cc @DougLea
Viktor Kl
On Fri, 17 May 2024 11:52:12 GMT, Doug Lea wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding a leak detection test for SynchronousQueue
>
> Looks good; thanks. I don't know why I
On Fri, 17 May 2024 11:35:55 GMT, Viktor Klang wrote:
>> Local testing seems to indicate that this fix (which mirrors what's done in
>> the FIFO mode) addresses the problem.
>>
>> But with that said, I haven't come up with a decent way of adding some form
>> o
> Local testing seems to indicate that this fix (which mirrors what's done in
> the FIFO mode) addresses the problem.
>
> But with that said, I haven't come up with a decent way of adding some form
> of regression test. Suggestions are most welcome. /cc @DougLea
Viktor Kl
On Thu, 16 May 2024 14:54:52 GMT, Viktor Klang wrote:
> Local testing seems to indicate that this fix (which mirrors what's done in
> the FIFO mode) addresses the problem.
>
> But with that said, I haven't come up with a decent way of adding some form
> of regression te
Local testing seems to indicate that this fix (which mirrors what's done in the
FIFO mode) addresses the problem.
But with that said, I haven't come up with a decent way of adding some form of
regression test. Suggestions are most welcome. /cc @DougLea
-
Commit messages:
- Memory
On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang wrote:
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample co
On Tue, 14 May 2024 14:51:20 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
On Tue, 14 May 2024 14:51:20 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable
t
> java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510)
> at REPL.$JShell$16B.lambda$main$1($JShell$16B.java:11)
> ... 1 more
Viktor Klang has updated the pull request incrementally with one additional
commit since the last revision
On Mon, 13 May 2024 18:16:55 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line
>> 392:
>>
>>> 390: return null;
>>> 391: if (x instanceof CancellationException)
>>> 392: throw new
On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang wrote:
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample co
On Mon, 13 May 2024 17:03:00 GMT, Chen Liang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the
On Mon, 13 May 2024 16:41:37 GMT, Viktor Klang wrote:
> This change adds wrapping of the CancellationException produced by
> CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
> information and align better with FutureTask.
>
> Running the sample co
This change adds wrapping of the CancellationException produced by
CompletableFuture::get() and CompletableFuture::join() to add more diagnostic
information and align better with FutureTask.
Running the sample code from the JBS issue in JShell will produce the following:
jshell>
On Sun, 12 May 2024 13:12:24 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang wrote:
> This is an attempt to be more clear about recommendations on Lock usage.
This pull request has now been integrated.
Changeset: 5053b70a
Author: Viktor Klang
URL:
https://git.openjdk.org/jdk/com
On Mon, 29 Apr 2024 11:48:08 GMT, Chen Liang wrote:
>> Primarily offering this PR for discussion, as Throwables throwing exceptions
>> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
>> unreasonable thing to do.
>>
>> Nevertheless, there is some things we can do, as
On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang wrote:
> Primarily offering this PR for discussion, as Throwables throwing exceptions
> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
> unreasonable thing to do.
>
> Nevertheless, there is some t
Primarily offering this PR for discussion, as Throwables throwing exceptions on
toString(), getLocalizedMessage(), or getMessage() seems like a rather
unreasonable thing to do.
Nevertheless, there is some things we can do, as witnessed in this PR.
-
Commit messages:
-
On Wed, 1 May 2024 10:03:25 GMT, Pavel Rappo wrote:
>> The grammar rules prefer "that" because it is a restrictive clause, even
>> though "which" might sound better. See for example:
>> https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
>
>> The grammar rules prefer "that"
On Fri, 10 May 2024 12:09:20 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2167:
>>
>>> 2165: }
>>> 2166: }
>>> 2167: return stat;
>>
>> @DougLea Since `stat` is a local, and is only written to once per branch it
>>
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang wrote:
> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`
This pull request has now been integrated.
Changeset: f12ed061
Author: Viktor Klang
URL:
https://git.openjdk.org/jdk/com
On Tue, 7 May 2024 14:58:00 GMT, Viktor Klang wrote:
> Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`
Tagging @PaulSandoz for review :)
-
PR Comment: https://git.openjdk.org/jdk/pull/19123#issuecomment-2099048586
Removes SORTED if not also ORDERED for escape-hatch `Stream::spliterator()`
-
Commit messages:
- Make sure that escape-hatch spliterator()s don't report SORTED if they
aren't also ORDERED
Changes: https://git.openjdk.org/jdk/pull/19123/files
Webrev:
On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang wrote:
>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> src/java
On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang wrote:
> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and
> status for Stream Gatherers.
This pull request has now been integrated.
Changeset: 2cc8eccb
Author:Viktor Klang
URL:
https://git.openjdk.o
On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang wrote:
>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> src/java
This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status
for Stream Gatherers.
-
Commit messages:
- Updating PreviewFeature.STREAM_GATHERERS to 473 - Second Preview
Changes: https://git.openjdk.org/jdk/pull/19003/files
Webrev:
On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang wrote:
> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and
> status for Stream Gatherers.
@AlanBateman Let me know if I should create a new JBS issue for this change, or
if it is fine to target the JEP JBS is
On Fri, 26 Apr 2024 17:59:39 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang wrote:
> This PR adds the exception documentation as per the ExecutorService API
> contract. I also took the liberty of adding @Override-annotations to be clear
> about intent.
This pull request has now been integrated.
Changeset:
> This is an attempt to be more clear about recommendations on Lock usage.
Viktor Klang has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
Co-autho
On Fri, 26 Apr 2024 11:43:06 GMT, Viktor Klang wrote:
> This is an attempt to be more clear about recommendations on Lock usage.
@stuart-marks Would this be better? 樂
-
PR Comment: https://git.openjdk.org/jdk/pull/18974#issuecomment-2079225009
This is an attempt to be more clear about recommendations on Lock usage.
-
Commit messages:
- Adding more clarification to proper usage of locks
Changes: https://git.openjdk.org/jdk/pull/18974/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18974=00
Issue:
This PR adds the exception documentation as per the ExecutorService API
contract. I also took the liberty of adding @Override-annotations to be clear
about intent.
-
Commit messages:
- 8296543 - adding javadoc for thrown exceptions from AbstractExecutorService
methods
Changes:
On Fri, 26 Apr 2024 08:08:25 GMT, Viktor Klang wrote:
> This PR adds the exception documentation as per the ExecutorService API
> contract. I also took the liberty of adding @Override-annotations to be clear
> about intent.
@pavelrappo @DougLea Looks good?
-
PR Comme
On Thu, 25 Apr 2024 13:34:50 GMT, Claes Redestad wrote:
>> When analyzing (startup) performance of the Classfile API I found this
>> opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>>
>> Performance improves across the board in existing microbenchmarks:
>>
>> Name
On Wed, 24 Apr 2024 23:15:45 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Wed, 24 Apr 2024 14:52:45 GMT, Brian Burkhalter wrote:
>> Using a subclass to count the number of invocations of toByteArray seems a
>> bit strange but in general it is more robust to not rely on a method that
>> may be overridden by a subclass. So I think the suggestion is good.
>
>
On Thu, 21 Mar 2024 18:01:38 GMT, Chen Liang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations for multiple-element immutable
ential(
Index::new,
Integrator.ofGreedy((idx, e, d) -> {
var current = idx.at++;
return !p.test(e) || d.push(current);
})
);
}
So you could do: list.stream().gather(indiciesWhere(predicate)).findFirst()
Cheers,
√
On Tue, 23 Apr 2024 07:27:02 GMT, Alan Bateman wrote:
> > Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?)
> > been explored/benchmarked?
>
> Yes, decided not to do because it's just guarding access to a byte[] and any
> changes can influence the inlining. Plus, it
On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>>
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
On Fri, 5 Apr 2024 23:13:39 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Thu, 4 Apr 2024 12:18:07 GMT, Viktor Klang wrote:
> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it
> is both competitive performance-wise as well as improve correctness.
>
> Below is the performance of `Stream::flatMap` (for reference types):
> // Short-circuiting:
>
> Benchmark (size) Mode Cnt Score Error Units
> FlatMap.par_iterate_double 10 thrpt 12 46336,834 ? 6803,751 ops/s
> FlatMap.par_iterate_double 100 thrpt 12 15365,884 ? 2750,656 ops/s
> FlatMap.par_iterate_doub
On Sat, 13 Apr 2024 09:20:17 GMT, Rémi Forax wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding additional, short-circuit-specific, cases to the FlatMap benchmark
>
> Hel
On Sat, 13 Apr 2024 09:04:36 GMT, Rémi Forax wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding additional, short-circuit-specific, cases to the FlatMap benchmark
>
> src/jav
> // Short-circuiting:
>
> Benchmark (size) Mode Cnt Score Error Units
> FlatMap.par_iterate_double 10 thrpt 12 46336,834 ? 6803,751 ops/s
> FlatMap.par_iterate_double 100 thrpt 12 15365,884 ? 2750,656 ops/s
> FlatMap.par_iterate_doub
On Thu, 11 Apr 2024 14:44:32 GMT, Chen Liang wrote:
>> Korov has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Use testNG builtin functionalities and modify the test function name
>
> Keep-alive, maybe people like @viktorklang-ora might
On Mon, 8 Apr 2024 16:47:24 GMT, Paul Sandoz wrote:
>> @PaulSandoz @AlanBateman I've added a commit to this PR which removes the
>> use of Gatherer for Stream::flatMap, but instead implements flatMap for all
>> of the pipelines using the same encoding which Gatherer would use. It seems
>>
e interesting:
>
> Before this PR:
>
> Benchmark(size) Mode Cnt ScoreError Units
> FlatMap.par_array10 thrpt 12 0,325 ? 0,004 ops/s
> FlatMap.par_iterate 100000 thrpt 12 0,106 ? 0,008 ops/s
> FlatMap.seq_array10 thrpt 12 0,
e interesting:
>
> Before this PR:
>
> Benchmark(size) Mode Cnt ScoreError Units
> FlatMap.par_array10 thrpt 12 0,325 ? 0,004 ops/s
> FlatMap.par_iterate 100000 thrpt 12 0,106 ? 0,008 ops/s
> FlatMap.seq_array10 thrpt 12
e interesting:
>
> Before this PR:
>
> Benchmark(size) Mode Cnt ScoreError Units
> FlatMap.par_array10 thrpt 12 0,325 ? 0,004 ops/s
> FlatMap.par_iterate 100000 thrpt 12 0,106 ? 0,008 ops/s
> FlatMap.seq_array10 thrpt 12
e interesting:
>
> Before this PR:
>
> Benchmark(size) Mode Cnt ScoreError Units
> FlatMap.par_array10 thrpt 12 0,325 ? 0,004 ops/s
> FlatMap.par_iterate 100000 thrpt 12 0,106 ? 0,008 ops/s
> FlatMap.seq_array10 thrpt 12
On Tue, 9 Apr 2024 10:04:44 GMT, Viktor Klang wrote:
>> This PR implements Gatherer-inspired encoding of `flatMap` that shows that
>> it is both competitive performance-wise as well as improve correctness.
>>
>> Below is the performance of `Stream::flatMap` (for referen
s/s
> FlatMap.seq_iterate 10 thrpt 12 812722,403 ? 160500,399 ops/s
> FlatMap.seq_iterate 100 thrpt 12 13542,472 ?118,769 ops/s
> FlatMap.seq_iterate1000 thrpt 12 157,056 ? 1,814 ops/s
Viktor Klang has updated the pull request incrementally wi
On Thu, 4 Apr 2024 12:18:07 GMT, Viktor Klang wrote:
> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it
> is both competitive performance-wise as well as improve correctness.
>
> Below is the performance of `Stream::flatMap` (for reference types):
On Mon, 8 Apr 2024 16:47:24 GMT, Paul Sandoz wrote:
> > @PaulSandoz @AlanBateman I've added a commit to this PR which removes the
> > use of Gatherer for Stream::flatMap, but instead implements flatMap for all
> > of the pipelines using the same encoding which Gatherer would use. It seems
> >
On Thu, 4 Apr 2024 12:18:07 GMT, Viktor Klang wrote:
> This PR implements Gatherer-inspired encoding of `flatMap` that shows that it
> is both competitive performance-wise as well as improve correctness.
>
> Below is the performance of `Stream::flatMap` (for reference types):
This PR implements Gatherer-inspired encoding of `flatMap` that shows that it
is both competitive performance-wise as well as improve correctness.
Below is the performance of `Stream::flatMap` (for reference types):
Before this PR:
Benchmark(size) Mode CntScore
initialization or finish, is it possible to have an "empty"
>input?
No, not an empty as in "absense of". You'd have to emit in the finisher then.
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: Ernie Rael
.N -> 1, which means that an empty input would yield a
single output.
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: core-libs-dev on behalf of Ernie Rael
Sent: Sunday, 7 April 2024 18:06
To: core-libs-dev@openjdk.org
Subject
On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang wrote:
> This is a draft PR with a potential solution to 8328366 without regressing
> 8327501.
>
> @DougLea To avoid regressions in the future, where would regression tests for
> this ideally be located?
This pull request has now
On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang wrote:
> This is a draft PR with a potential solution to 8328366 without regressing
> 8327501.
>
> @DougLea To avoid regressions in the future, where would regression tests for
> this ideally be located?
Follow-up issue regardi
On Wed, 20 Mar 2024 17:15:49 GMT, Mandy Chung wrote:
>> This is a draft PR with a potential solution to 8328366 without regressing
>> 8327501.
>>
>> @DougLea To avoid regressions in the future, where would regression tests
>> for this ideally be located?
>
>
On Fri, 29 Mar 2024 20:48:09 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
1 - 100 of 461 matches
Mail list logo
