[8u] Regression after JDK-8237117: Better ForkJoinPool behavior

Chris Hegarty chris.hegarty at oracle.com
Sun Jul 19 21:37:13 UTC 2020


I added a comment to the JIRA issue. Looks like an error with the backport.

-Chris.

> On 19 Jul 2020, at 12:26, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> Sorry that we missed noticing this change, which also conflicts with jsr166 jdk8 version. I am also puzzled why the ForkJoinWorkerThread constructor was changed to ignore the acc argument. Unless there is some good reason for changing (in some different way), it should be reverted back to:
> 
>     ForkJoinWorkerThread(ForkJoinPool pool, ThreadGroup threadGroup,
>                          AccessControlContext acc) {
>         super(threadGroup, null, "aForkJoinWorkerThread");
>         U.putOrderedObject(this, INHERITEDACCESSCONTROLCONTEXT, acc);
>         eraseThreadLocals(); // clear before registering
>         this.pool = pool;
>         this.workQueue = pool.registerWorker(this);
>     }
> 
> On 7/17/20 1:32 PM, Anton Kozlov wrote:
>> Hi,
>> 
>> backport of JDK-8237117 [1] apparently introduces a regression.
>> 
>> It was found during runs of running lucene-solr 8.2.0 [2].
>> The problem reproduces on a simpler example (in attach) on openjdk8u262-b10[3], but doesn't reproduce on openjdk8u252-b09[4].
>> 
>> When I comment out line [5], the lucene-solr test and the provided reproducer passes.
>> 
>> The change original version is [6].
>> Newer JDKs have two package private constructors ForkJoinWorkerThread, that call base protected constructor and then initialize inherited ACC to the INNOCUOUS_ACC.
>> When users subclass ForkJoinWorkerThread, they are free to provide any ACC, which is by default is the current ACC.
>> Same was in 8u until backport of JDK-8237117, which changes default ACC to INNOCUOUS_ACC instead of the current one.
>> 
>> The backport in 8u is also inconsistent with one in jdk11u[7], which does not change ACC in the protected constructor.
>> The reproducer also passes on openjdk11.0.8 [8], which do have own backport of the original patch.
>> 
>> Please discuss. It doesn't look the 8u backport is correct.
>> 
>> I've opened JDK-8249677 to track the issue
>> 
>> Thanks,
>> Anton
>> 
>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe
>> [2] https://github.com/apache/lucene-solr/commit/31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe
>> [3] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b10
>> [4] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u252-b09
>> [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe#l1.19
>> [6] https://hg.openjdk.java.net/jdk/jdk/rev/50d5266f275f
>> [7] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/0e9eb367df7a/src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l92
>> [8] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.8%2B10



More information about the jdk8u-dev mailing list