RFR: 8342486: Implement JEP 505: Structured Concurrency (Fifth Preview) [v8]

[Chen Liang]

On Tue, 15 Apr 2025 06:36:20 GMT, Alan Bateman <alanb at openjdk.org> 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/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
>> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
>> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
>> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
>> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>>  
>> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.
>
> 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
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Sync up from loom repo
>  - Merge branch 'master' into JDK-8342486
>  - Merge branch 'master' into JDK-8342486
>  - Fix link
>  - Merge branch 'master' into JDK-8342486
>  - Sync up impl/tests form loom repo
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3090e218...418bc3d3

src/java.base/share/classes/java/util/concurrent/Joiners.java line 93:

> 91:             return (state == Subtask.State.FAILED)
> 92:                     && (firstException == null)
> 93:                     && FIRST_EXCEPTION.compareAndSet(this, null, subtask.exception());

1. Should we add the other exceptions as suppressed to the first?
2. If we have stable values, we can use a stable value to racily set the first exception.

src/java.base/share/classes/java/util/concurrent/Joiners.java line 190:

> 188:      * A joiner that returns a stream of all subtasks.
> 189:      */
> 190:     static class AllSubtasks<T> implements Joiner<T, Stream<Subtask<T>>> {

Suggestion:

    static final class AllSubtasks<T> implements Joiner<T, Stream<Subtask<T>>> {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2043738283
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r2043741615