RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v16]

[Doug Lea]

On Sun, 28 Dec 2025 17:34:50 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea 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 21 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - recheck avoiding cross-class offsets
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - Check reworked ordering control
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - Check diagnosis
>>  - Avoid double-filtering
>>  - Merge branch 'openjdk:master' into JDK-8373118
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/98c9441f...228ec84d
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1981:
> 
>> 1979:                                     if (src != qid)
>> 1980:                                         w.source = src = qid;
>> 1981:                                     w.topLevelExec(t, fifo);
> 
> Given that topLevelExec is tiny, and only called from this line, it might be better to just inline it here, since we know that `t` is originally not-null here, we can defer the initial null-check to only apply to subsequent tasks:
> 
> 
>             do {
>                 t.doExec();
>             } while ((t = w.nextLocalTask(fifo)) != null);

Except that normally, topLevelExec shouldn't be inlined in runWorker because it hits megamorphic FJT.exec(). Which is actually good in some artificial benchmarks with only one task type, but rarely in actual use. But there might be ways to place some @DontInline to control better. I'll try some out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2659003373