On Wed, 23 Apr 2025 10:10:54 GMT, Viktor Klang wrote:
> This Pull Request replaces the uses of Field + setAccessible to modify final
> fields in java.util.concurrent with Unsafe.
This pull request has now been integrated.
Changeset: 356c4d9c
Author:Viktor Klang
URL:
On Thu, 24 Apr 2025 11:27:32 GMT, Doug Lea wrote:
>> The set only has a map field, and AbstractSet does not define any additional
>> field. The map should be fine too - two fields in AbstractMap are cleared
>> when cloning happens, so recreating a map from a constructor should have the
>> same
On Wed, 23 Apr 2025 16:23:00 GMT, Chen Liang wrote:
>> Viktor Klang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adding a releaseFence() to ConcurrentskipListSet.clone()
>
> Thanks. We can investigate ho
On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Make public constuctor private
👍
-
Marked as r
On Thu, 24 Apr 2025 09:21:03 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 370 commits:
>
> - Revert unwanted changes
> - Mer
On Wed, 23 Apr 2025 15:07:33 GMT, Raffaello Giulietti
wrote:
>> @liach Not sure I understand, could you elaborate a bit?
>
> @viktorklang-ora Before approving, what is the status of the copyright
> notices? There seem to be no years to update...
@rgiulietti These are the JSR166 files, so I did
On Wed, 23 Apr 2025 15:18:49 GMT, Viktor Klang wrote:
>> This Pull Request replaces the uses of Field + setAccessible to modify final
>> fields in java.util.concurrent with Unsafe.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit si
> This Pull Request replaces the uses of Field + setAccessible to modify final
> fields in java.util.concurrent with Unsafe.
Viktor Klang has updated the pull request incrementally with one additional
commit since the last revision:
Adding a releaseFence() to ConcurrentskipListSet
On Wed, 23 Apr 2025 14:06:27 GMT, Chen Liang wrote:
>> This Pull Request replaces the uses of Field + setAccessible to modify final
>> fields in java.util.concurrent with Unsafe.
>
> Seems these are used mainly for cloning: is it possible for us to just use
> `readResolve` to resolve an alterna
On Wed, 23 Apr 2025 10:44:05 GMT, Per Minborg wrote:
>> This Pull Request replaces the uses of Field + setAccessible to modify final
>> fields in java.util.concurrent with Unsafe.
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
> line 534:
>
>> 532: U.pu
On Wed, 23 Apr 2025 12:12:26 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Replace 'contents' with 'result' in the docs
Thanks for all
On Wed, 23 Apr 2025 10:38:22 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 365 commits:
>
> - Replace 'content' with 'contents
This Pull Request replaces the uses of Field + setAccessible to modify final
fields in java.util.concurrent with Unsafe.
-
Commit messages:
- Update ConcurrentSkipListSet, CopyOnWriteArrayList, and AtomicReferenceArray
to use Unsafe rather than Field.setAccessible
Changes: https:/
On Tue, 22 Apr 2025 15:09:49 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reformat docs
src/java.base/share/classes/java/lang/StableVa
On Fri, 18 Apr 2025 14:17:37 GMT, Jorn Vernee wrote:
>> I'm definitely not an expert here, so I'll defer to someone more
>> knowledgable :)
>
> I asked around/looked this up, and it seems 'contents' would be more correct
> here, since a StableValue is primarily a container of things (you put th
On Fri, 18 Apr 2025 18:25:54 GMT, Chen Liang wrote:
>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>>
>> For calling little color management system
>> https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>>
>>
On Thu, 10 Apr 2025 14:19:25 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Address comments on original vs underlying
Last review pass?
On Tue, 15 Apr 2025 13:38:21 GMT, Alan Bateman wrote:
>> I'm not sure where we are on this topic. Clearly there's an edge between the
>> pre-join and post-join phases.
>
> Yes, but it would be a topic for a different PR as we haven't changed
> anything here.
Agreed
-
PR Review Co
On Tue, 15 Apr 2025 06:36:20 GMT, Alan Bateman wrote:
>> Changes for [JEP 505: Structured Concurrency (Fifth
>> Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview
>> the API with some changes, specifically:
>>
>> - A
>> [StructuredTaskScope](https://download.java.net/j
On Thu, 7 Nov 2024 10:51:15 GMT, Alan Bateman wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 15 commits:
>>
>> - Add JEP number, update copyright headers
>> - Merge branch 'master' into JDK-8342486
>> -
((h & ~(1L << 32)) == 0) // if calculated bit is not set, the calculate
hash = h = (1L << 32) | (isLatin1()
? StringLatin1.hashCode(value)
: StringUTF16.hashCode(value));
return (int)h;
}
Cheers,
√
Viktor Klang
Software Architect, Java Platf
On Thu, 10 Apr 2025 10:26:36 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Improve docs as per comments
src/java.base/share/classes/jav
On Thu, 10 Apr 2025 06:34:24 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 307 commits:
>
> - Fix typo
> - Merge branch 'mast
On Wed, 9 Apr 2025 05:56:28 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 889:
>>
>>> 887: private void parkTimeoutExpired() {
>>> 888: assert !VirtualThread.currentThread().isVirtual();
>>> 889: if (!getAndSetParkPermit(true)
>>
>
On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman wrote:
> Follow up to JDK-8319447 to change the VirtualThread implementation to use
> FJP's delayed task handling.
>
> The SPTE based implementation is not removed. It will continue to be used by
> tests. If custom schedulers are exposed in the fu
On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman wrote:
> Follow up to JDK-8319447 to change the VirtualThread implementation to use
> FJP's delayed task handling.
>
> The SPTE based implementation is not removed. It will continue to be used by
> tests. If custom schedulers are exposed in the fu
On Tue, 8 Apr 2025 05:12:00 GMT, Jean-Noël Rouvignac wrote:
>> Viktor Klang 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
On Tue, 8 Apr 2025 09:36:09 GMT, Viktor Klang wrote:
> Updating the ReentrantReadWriteLock documentation
This pull request has now been integrated.
Changeset: 676cfae9
Author: Viktor Klang
URL:
https://git.openjdk.org/jdk/commit/676cfae91c8bd4799adfedff2ad59a9aab953ece
Stats:
On Tue, 8 Apr 2025 10:08:26 GMT, Viktor Klang wrote:
>> Updating the ReentrantReadWriteLock documentation
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> src/java.base/share/classes/ja
> Updating the ReentrantReadWriteLock documentation
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
Removing sp
Updating the ReentrantReadWriteLock documentation
-
Commit messages:
- Adding links
- Updates ReentrantReadWriteLock to state the new hold capacities
Changes: https://git.openjdk.org/jdk/pull/24502/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24502&range=00
Issue: htt
On Wed, 26 Mar 2025 16:19:16 GMT, Viktor Klang wrote:
> I'm breaking this change out as a separate improvement, since it will not be
> generally possible to adjust these limits on the j.u.c primitives since they
> might already use a backing `long` to pack in information whi
28-bit atomics to widen them, and it still
> infeasible to change return types of pre-existing APIs).
Viktor Klang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains two commits:
- Make sure that the test fails in case of an Interrupte
On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang wrote:
> This PR reverts the deactivation changes of the updates to FJP introduced in
> JDK-8319447.
This pull request has now been integrated.
Changeset: 40210333
Author:Viktor Klang
URL:
https://git.openjdk.org/jdk/
On Mon, 7 Apr 2025 14:03:13 GMT, Alan Bateman wrote:
>> Viktor Klang 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 two addi
On Wed, 2 Apr 2025 13:09:01 GMT, Viktor Klang wrote:
>> test/jdk/java/util/concurrent/tck/ReentrantReadWriteLock20Test.java line 94:
>>
>>> 92: next.join();
>>> 93: } catch (InterruptedException ie) {
>>> 94:
On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang wrote:
> This PR reverts the deactivation changes of the updates to FJP introduced in
> JDK-8319447.
@AlanBateman @DougLea Testing-wise this is ready for review and, hopefully,
integration.
-
PR Comment: https://git.openjdk.o
On Sun, 6 Apr 2025 12:36:43 GMT, Viktor Klang wrote:
> This PR reverts the deactivation changes of the updates to FJP introduced in
> JDK-8319447.
@AlanBateman @DougLea This is a draft PR for now. I need to run some additional
tier-testing in order to promote to a &qu
This PR reverts the deactivation changes of the updates to FJP introduced in
JDK-8319447.
-
Commit messages:
- Addresses deactivation races introduced by JDK-8319447
Changes: https://git.openjdk.org/jdk/pull/24473/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24473&range
On Thu, 3 Apr 2025 08:39:47 GMT, Per Minborg wrote:
>> src/java.base/share/classes/java/lang/StableValue.java line 377:
>>
>>> 375: *
>>> 376: * Thread Safety
>>> 377: * The content of a stable value is guaranteed to be set at most once.
>>> If competing
>>
>> Suggestion:
>>
>> * The cont
On Wed, 2 Apr 2025 13:44:47 GMT, Alan Bateman wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add info that Map#values and Map#entrySet are stable
>
> src/java.base/share/classes/java/lang/StableValue.java line 455:
On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add info that Map#values and Map#entrySet are stable
Thanks f
On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add info that Map#values and Map#entrySet are stable
src/java
On Wed, 2 Apr 2025 14:06:22 GMT, Viktor Klang wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add info that Map#values and Map#entrySet are stable
>
> src/java.base/share/classes/java
On Wed, 2 Apr 2025 13:22:44 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add info that Map#values and Map#entrySet are stable
src/java
On Wed, 2 Apr 2025 09:36:51 GMT, Alan Bateman wrote:
>> I'm breaking this change out as a separate improvement, since it will not be
>> generally possible to adjust these limits on the j.u.c primitives since they
>> might already use a backing `long` to pack in information which needs to be
>>
On Fri, 11 Oct 2024 15:49:33 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 collect
On Tue, 1 Apr 2025 10:56:25 GMT, Alan Bateman wrote:
> ForkJoinPool20Test::testFixedDelaySequence is failing intermittently. The
> assert that checks that the periodically tasks only executes 8 times is
> removed, it may run more than this before it cancelled.
Marked as reviewed by vklang (Rev
On Fri, 28 Mar 2025 23:39:30 GMT, Chen Liang wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> docs
>
> There shouldn't be.
>
> 1. This just allocates a new promise for a single-threaded computation; the
> promise ju
On Fri, 28 Mar 2025 16:27:28 GMT, Roger Riggs wrote:
>> I'm breaking this change out as a separate improvement, since it will not be
>> generally possible to adjust these limits on the j.u.c primitives since they
>> might already use a backing `long` to pack in information which needs to be
>>
On Thu, 27 Mar 2025 23:20:56 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Mar 2025 19:44:48 GMT, Chen Liang wrote:
>> The recent patch #23866 makes calling `ClassValue::remove()` from
>> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
>> value risk from the method.
>>
>> The proposed fix is to preserve the stale value risk fix
On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman wrote:
>> I'm breaking this change out as a separate improvement, since it will not be
>> generally possible to adjust these limits on the j.u.c primitives since they
>> might already use a backing `long` to pack in information which needs to be
>
On Thu, 27 Mar 2025 11:30:11 GMT, Alan Bateman wrote:
>> I'm breaking this change out as a separate improvement, since it will not be
>> generally possible to adjust these limits on the j.u.c primitives since they
>> might already use a backing `long` to pack in information which needs to be
>
On Sun, 2 Mar 2025 06:55:09 GMT, He-Pin(kerr) wrote:
>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an
>> IllegalArgumentException with an error message `null`, which is not helpful.
>>
>> Modification:
>> Add detail error messages.
>>
>> Result:
>> H
I'm breaking this change out as a separate improvement, since it will not be
generally possible to adjust these limits on the j.u.c primitives since they
might already use a backing `long` to pack in information which needs to be
updated atomically (would require 128-bit atomics to widen them, a
On Wed, 26 Mar 2025 19:52:16 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3932:
>>
>>> 3930: * @since 25
>>> 3931: */
>>> 3932: public int getDelayedTaskCount() {
>>
>> @DougLea It would seem more consistent to have this return a
On Mon, 17 Mar 2025 00:40:46 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/util/ImmutableCollections.java line 798:
>>
>>> 796: throw new IndexOutOfBoundsException(i);
>>> 797: }
>>> 798: }
>>
>> I think `orElseSet` should be outside of the `try`
On Tue, 25 Mar 2025 19:57:54 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Wed, 26 Mar 2025 13:14:45 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3743:
>>
>>> 3741: * @since 25
>>> 3742: */
>>> 3743: public void cancelDelayedTasksOnShutdown() {
>>
>> @DougLea Should this really be possible to enab
On Tue, 25 Feb 2025 22:41:07 GMT, Doug Lea wrote:
>>> @sunmisc You are right that it would be nice if there were a way to
>>> efficiently use getAndSet here because a failed reference CAS hits slow
>>> paths that vary across GCs. But all of the ways I know to do this are much
>>> worse.
>>
>>
On Tue, 25 Mar 2025 19:57:54 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sat, 22 Mar 2025 11:09:03 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sun, 9 Mar 2025 17:17:50 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (as
On Mon, 10 Mar 2025 14:34:42 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Disambiguate caller-runs vs Interruptible
>
> src/java.base/share/classes/java/util/concurre
On Sat, 1 Mar 2025 15:43:17 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (as
On Sat, 1 Mar 2025 15:43:17 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (as
On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) wrote:
>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an
>> IllegalArgumentException with an error message `null`, which is not helpful.
>>
>> Modification:
>> Add detail error messages.
>>
>> Result:
>>
On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) wrote:
>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an
>> IllegalArgumentException with an error message `null`, which is not helpful.
>>
>> Modification:
>> Add detail error messages.
>>
>> Result:
>>
On Mon, 24 Feb 2025 16:21:33 GMT, He-Pin(kerr) wrote:
>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an
>> IllegalArgumentException with an error message `null`, which is not helpful.
>>
>> Modification:
>> Add detail error messages.
>>
>> Result:
>>
On Wed, 26 Feb 2025 10:13:12 GMT, Alan Bateman wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Standardize parameter checking
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3131:
>
>> 3129
On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Sun, 23 Feb 2025 15:26:48 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote:
>> (Copied from https://bugs.openjdk.org/browse/JDK-8319447)
>>
>> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is
>> both ill-suited for many (if not most) of its applications, and is a
>> performance bottleneck (a
d.
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: Remi Forax
Sent: Saturday, 15 February 2025 15:44
To: Viktor Klang ; Fabian Meumertzheim
Cc: Paul Sandoz ; core-libs-dev
Subject: [External] : Re: JDK-8072840: Presizing for Stream
ing a finalized feature.
It's great that you started this conversation, Fabian!
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: core-libs-dev on behalf of Paul Sandoz
Sent: Thursday, 13 February 2025 20:18
To: Fabian Meumertzheim
Cc:
eed to be threaded through the
chain of gatherers and emerge on the other side. This is slightly more involved
than just communicating characteristics, since it is information based off of
the stream and not merely the operation itself.
Cheers,
√
Viktor Klang
Software Architect,
-augmentation) to enable more sophisticated
optimizations—because ultimately the availability of the information throughout
the pipeline is going to be important for Collector.
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: core-libs
On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) wrote:
> Motivation:
> When a user passes a wrong parameter, the current implementation throws an
> IllegalArgumentException with an error message `null`, which is not helpful.
>
> Modification:
> Add detail error messages.
>
> Result:
> Helpful m
On Tue, 11 Feb 2025 08:39:51 GMT, Per Minborg wrote:
>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an
>> IllegalArgumentException with an error message `null`, which is not helpful.
>>
>> Modification:
>> Add detail error messages.
>>
>> Result:
>> H
On Sat, 18 Jan 2025 11:35:28 GMT, He-Pin(kerr) wrote:
>> Motivation:
>> When a user passes a wrong parameter, the current implementation throws an
>> IllegalArgumentException with an error message `null`, which is not helpful.
>>
>> Modification:
>> Add detail error messages.
>>
>> Result:
>>
ing
support for such in (at least) GathererOp needs further study before
contemplating making any changes to mapConcurrent()'s interruption policy.
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: Jige Yu
Sent: Thursday, 6 Febru
On Thu, 16 Jan 2025 13:46:16 GMT, Viktor Klang wrote:
> Removes ThreadPoolExecutor javadoc which mentions RuntimePermission.
This pull request has now been integrated.
Changeset: 5ec1aae2
Author: Viktor Klang
URL:
https://git.openjdk.org/jdk/com
1 - 100 of 762 matches
Mail list logo
