[crac] RFR: Merge jdk:jdk-25+26

[Timofei Pushkin]

On Wed, 23 Jul 2025 17:58:09 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Since the merge for [JDK-8352675](https://bugs.openjdk.org/browse/JDK-8352675) is split into a separate PR (https://github.com/openjdk/crac/pull/247), I cherry-picked the current version and merging other changes on top of it. It will likely require rebase on top of the final version later.
> 
> Attaching output of `--diff-merges=remerge`
> 
> <details>
> 
> <summary>Conflicts</summary>
> 
> 
> commit 5035f463900712ae47b7e1adfeff609bc1d66116 (HEAD -> merge-jdk, dmitry-crac/merge-jdk)
> Merge: d61227fe01d c59e44a7aa2
> Author: Dmitry Cherepanov <dcherepanov at azul.com>
> Date:   Tue Jul 22 13:30:47 2025 +0400
> 
>     Merge with jdk-25+26
> 
> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> remerge CONFLICT (content): Merge conflict in .github/workflows/main.yml
> index 8cf745c1cff..02c6f3d2668 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -310,11 +310,7 @@ jobs:
>      uses: ./.github/workflows/build-windows.yml
>      with:
>        platform: windows-x64
> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection)
>        msvc-toolset-version: '14.44'
> -=======
> -      msvc-toolset-version: '14.43'
> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual)
>        msvc-toolset-architecture: 'x86.x64'
>        configure-arguments: ${{ github.event.inputs.configure-arguments }}
>        make-arguments: ${{ github.event.inputs.make-arguments }}
> @@ -326,11 +322,7 @@ jobs:
>      uses: ./.github/workflows/build-windows.yml
>      with:
>        platform: windows-aarch64
> -<<<<<<< d61227fe01d (8352675: Support Intel AVX10 converged vector ISA feature detection)
>        msvc-toolset-version: '14.44'
> -=======
> -      msvc-toolset-version: '14.43'
> ->>>>>>> c59e44a7aa2 (8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual)
>        msvc-toolset-architecture: 'arm64'
>        make-target: 'hotspot'
>        extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin'
> @@ -369,17 +361,17 @@ jobs:
>        runs-on: ubuntu-22.04
>        debug-suffix: -debug
>  
> -  test-linux-x64-static:
> -    name: linux-x64-static
> -    needs:
> -      - build-linux-x64
> -      - build-linux-x64-static
> -    uses: ./.github/workflows/test.yml
> -    with:
> -      platform: linux-x64
> -      bootjdk-platform: linux-x64
> -      runs-on: ubuntu-22.04
> -      static-suffix: "-static"
> +#  test-linux-x64-static:
> +#    name: linux-x64-static
> +#    needs:
> +#      - build-linux-x64
> +#      - build-lin...

Have not finished the review yet, stopped on the JFR changes in the conflicts list, will continue tomorrow

src/hotspot/share/gc/z/zUncommitter.cpp line 85:

> 83:       // Wait
> 84:       _lock.wait(remaining_timeout_ms);
> 85:       now = os::elapsedTime();

>From the conflict resolution:

       _lock.wait(remaining_timeout_ms);
-
       now = os::elapsedTime();

Probably an accidental change. Better to stay closer to the mainline, i.e. retain the empty line

src/hotspot/share/gc/z/zUncommitter.cpp line 435:

> 433:   {
> 434:     ZLocker<ZConditionLock> locker(&_lock);
> 435:     _force_uncommit = true;

Shouldn't all reads and writes to `_force_uncommit` be guarded by the same lock since it is done by different threads? Currently there are two different locks for writing and some reads are unguarded at all. I believe using `_lock` everywhere is fine: yes, waiting in `wait_for_finish_force_uncommit` will have more unneeded wake-ups but there probably won't be too many.

src/hotspot/share/gc/z/zUncommitter.cpp line 444:

> 442: void ZUncommitter::wait_for_finish_force_uncommit() {
> 443:   ZLocker<ZConditionLock> locker(&_force_uncommit_lock);
> 444:   while (_force_uncommit) {

Have not checked but I believe with `-XX:-ZUncommit` we will wait here forever since the uncommitting threads will be doing nothing

src/hotspot/share/gc/z/zUncommitter.cpp line 447:

> 445:     _force_uncommit_lock.wait();
> 446:   }
> 447: }

This method is used in just one place above, maybe inline it there? To me it would improve readability in this case (I initially assumed it is used somewhere else too).

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

PR Review: https://git.openjdk.org/crac/pull/248#pullrequestreview-3052735414
PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229235172
PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229337886
PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229317631
PR Review Comment: https://git.openjdk.org/crac/pull/248#discussion_r2229274620