RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v8]

[Doug Lea]

On Thu, 11 Sep 2025 12:29:53 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revive topLevelExec, adjust occrdingly; small teaks and copy-edits
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 575:
> 
>> 573:      * or non-emptiness; all of which usually cause more activations
>> 574:      * than necessary (see below). (Method signalWork is also used as
>> 575:      * failsafe in case of Thread failures in deregisterWorker.)
> 
> I think it is worth elaborating what this failsafe enables (i.e. how does it failsafe these failures)

added: , to
     * activate or create a new worker to replace them).

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 598:
> 
>> 596:      * needs unparking upon signal.
>> 597:      *
>> 598:      * When tasks are constructed as (recursive) dags, top-level
> 
> Suggestion:
> 
>      * When tasks are constructed as (recursive) DAGs, top-level

Done

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 612:
> 
>> 610:      * stalls when tasks cannot be taken because other workers have
>> 611:      * not finished poll operations, which is detected by reading
>> 612:      * ahead in queue arrays. In both caes, workers restart scans in a
> 
> Suggestion:
> 
>      * ahead in queue arrays. In both cases, workers restart scans in a

thanks

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1224:
> 
>> 1222:             if ((this.owner = owner) == null) {
>> 1223:                 phase = id | IDLE;
>> 1224:                 array = new ForkJoinTask<?>[INITIAL_QUEUE_CAPACITY];
> 
> Might be better to assign the array *before* assigning the phase as the latter is a volatile write?

thanks; done.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1951:
> 
>> 1949:     final void runWorker(WorkQueue w) {
>> 1950:         if (w != null) {
>> 1951:             int phase = w.phase;
> 
> Given that this is a volatile read, and presuming that the timing of this read is important, perhaps add a comment on this line?

No longer apples after reworking code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348750133
PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348751688
PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348752724
PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348755855
PR Review Comment: https://git.openjdk.org/jdk/pull/26479#discussion_r2348760550