[jdk21u-dev] RFR: 8342905: Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501 redux [v3]

Tue Dec 3 16:42:45 UTC 2024

On Tue, 3 Dec 2024 16:11:58 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to propose a [JDK-8342905](https://bugs.openjdk.org/browse/JDK-8342905 "Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501 redux") (openjdk/jdk23u at 872ae1347198408ffd62559ca8c1a7420c4a8108) backport from 23u to 21u.
>> 
>> The backport is not clean, for the following reasons:
>> 
>> * The `jdk.internal.access.JavaLangAccess` import context in `ForkJoinPool.java` has changed from 21u to 23u, due to [JDK-8288899](https://bugs.openjdk.org/browse/JDK-8288899 "java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted"") (openjdk/jdk at 667cca9d7aef1ff4abe630cefaac34c0b1646925)
>> * The `jdk.internal.access.JavaLangAccess::allowSecurityManager` method didn't exist in 21u, so I picked it from [JDK-8296244](https://bugs.openjdk.org/browse/JDK-8296244 "Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs") (openjdk/jdk at d32746ef4a0ce6fec558274244321991be141698)
>>     * We don't need [JDK-8296244](https://bugs.openjdk.org/browse/JDK-8296244 "Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs"), just the access to the `System::allowSecurityManager` private method
>>     * I don't see [JDK-8296244](https://bugs.openjdk.org/browse/JDK-8296244 "Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs") as a possible dependency candidate, given it is a much broader change with its own CSR affecting the Java SE API and only approved for 23
>> 
>> This pull request depends on @martinuy's #1181.
>> 
>> #### Testing
>> 
>> As part of our testing, we observed all the tests pass in the following categories:
>> 
>> * `jdk:tier1` (see [GitHub Actions run](https://github.com/franferrax/jdk21u-dev/actions/runs/12126257318))
>> * `jdk/java/util/concurrent/forkjoin`
>> * `jdk/java/util/concurrent/tck`
>> 
>> Additionally, an internal test for [JDK-8237117](https://bugs.openjdk.org/browse/JDK-8237117 "Better ForkJoinPool behavior") was executed without issues.
>
> Francisco Ferrari Bihurriet 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 three additional commits since the last revision:
> 
>  - Merge master
>  - Backport 872ae1347198408ffd62559ca8c1a7420c4a8108
>  - 8344993: [21u] Re-introduce 8327501 and 8328366 to the JDK
>    
>    Revert "8341989: [21u] Back out JDK-8327501 and JDK-8328366"
>    
>    This reverts commit dfcd8d2eecfe62e91070244d8eb10906dc3c812d.

Please note that the old PR diff exactly matches the new one:

* Old diff: f02d74fb73125f57ed1bac82474a0d9a224a35bf (previous tip of this PR branch) against its parent, 67a36bded7f03fc7aee54372e71f8016d67971fd (tip of #1181, on which this PR depended)
* New diff: 84a0ff07baa37d1a93e698f29a3c1bd6fa0bfd45 (current tip of this PR branch) against its second parent, 96a3a88ee206680ba06c6ed876b538de41ff511c (current tip of `master`)

For example the following commands:

git diff 67a36bded7f03fc7aee54372e71f8016d67971fd f02d74fb73125f57ed1bac82474a0d9a224a35bf | sha512sum
git diff 96a3a88ee206680ba06c6ed876b538de41ff511c 84a0ff07baa37d1a93e698f29a3c1bd6fa0bfd45 | sha512sum

Both produce the same output:

0a7bdece0a0182399b03b7760046a12866781c7d7e519cfa052e93da9bf65b3f9d12e389bee37e86d52cf1fa0a841f5bc8aba94e9d6524aacff441468b67f2a4  -

Anyway, we'll want to wait for [run 12143610533](https://github.com/franferrax/jdk21u-dev/actions/runs/12143610533) before integrating.

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/1192#issuecomment-2515061046