Jdk 8333664

.editorconfig

@@ -0,0 +1,7 @@
+root = true
+
+[*.{cpp,hpp,c,h,java,cc,hh,m,mm,S,md,properties,gmk,m4,ac}]
+trim_trailing_whitespace = true
+
+[Makefile]
+trim_trailing_whitespace = true

.github/actions/do-build/action.yml

@@ -1,5 +1,5 @@
 #
-# Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2022, 2025, Oracle and/or its affiliates. All rights reserved.
 # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 #
 # This code is free software; you can redistribute it and/or modify it
@@ -42,7 +42,7 @@ runs:
     - name: 'Build'
       id: build
       run: >
-        make LOG=info ${{ inputs.make-target }}
+        make -k LOG=info ${{ inputs.make-target }}
         || bash ./.github/scripts/gen-build-failure-report.sh "$GITHUB_STEP_SUMMARY"
       shell: bash
 

.github/actions/upload-bundles/action.yml

@@ -32,6 +32,9 @@ inputs:
   debug-suffix:
     description: 'File name suffix denoting debug level, possibly empty'
     required: false
+  bundle-suffix:
+    description: 'Bundle name suffix, possibly empty'
+    required: false
 
 runs:
   using: composite
@@ -75,7 +78,7 @@ runs:
     - name: 'Upload bundles artifact'
       uses: actions/upload-artifact@v4
       with:
-        name: bundles-${{ inputs.platform }}${{ inputs.debug-suffix }}
+        name: bundles-${{ inputs.platform }}${{ inputs.debug-suffix }}${{ inputs.bundle-suffix }}
         path: bundles
         retention-days: 1
       if: steps.bundles.outputs.bundles-found == 'true'

.github/workflows/build-linux.yml

@@ -61,6 +61,9 @@ on:
       make-arguments:
         required: false
         type: string
+      bundle-suffix:
+        required: false
+        type: string
 
 jobs:
   build-linux:
@@ -71,10 +74,6 @@ jobs:
       fail-fast: false
       matrix:
         debug-level: ${{ fromJSON(inputs.debug-levels) }}
-        include:
-          - debug-level: debug
-            flags: --with-debug-level=fastdebug
-            suffix: -debug
 
     steps:
       - name: 'Checkout the JDK source'
@@ -118,7 +117,7 @@ jobs:
         run: >
           bash configure
           --with-conf-name=${{ inputs.platform }}
-          ${{ matrix.flags }}
+          ${{ matrix.debug-level == 'debug' && '--with-debug-level=fastdebug' || '' }}
           --with-version-opt=${GITHUB_ACTOR}-${GITHUB_SHA}
           --with-boot-jdk=${{ steps.bootjdk.outputs.path }}
           --with-jtreg=${{ steps.jtreg.outputs.path }}
@@ -133,17 +132,14 @@ jobs:
       - name: 'Build'
         id: build
         uses: ./.github/actions/do-build
-        env:
-          # Only build static-libs-bundles for release builds.
-          # For debug builds, building static-libs often exceeds disk space.
-          STATIC_LIBS: ${{ matrix.debug-level == 'release' && 'static-libs-bundles' }}
         with:
-          make-target: '${{ inputs.make-target }} ${STATIC_LIBS} ${{ inputs.make-arguments }}'
+          make-target: '${{ inputs.make-target }} ${{ inputs.make-arguments }}'
           platform: ${{ inputs.platform }}
-          debug-suffix: '${{ matrix.suffix }}'
+          debug-suffix: "${{ matrix.debug-level == 'debug' && '-debug' || '' }}"
 
       - name: 'Upload bundles'
         uses: ./.github/actions/upload-bundles
         with:
           platform: ${{ inputs.platform }}
-          debug-suffix: '${{ matrix.suffix }}'
+          debug-suffix: "${{ matrix.debug-level == 'debug' && '-debug' || '' }}"
+          bundle-suffix: ${{ inputs.bundle-suffix }}

.github/workflows/main.yml

@@ -225,6 +225,43 @@ jobs:
       make-arguments: ${{ github.event.inputs.make-arguments }}
     if: needs.prepare.outputs.linux-x64-variants == 'true'
 
+  build-linux-x64-static:
+    name: linux-x64-static
+    needs: prepare
+    uses: ./.github/workflows/build-linux.yml
+    with:
+      platform: linux-x64
+      make-target: 'static-jdk-image'
+      # There are issues with fastdebug static build in GHA due to space limit.
+      # Only do release build for now.
+      debug-levels: '[ "release" ]'
+      gcc-major-version: '10'
+      configure-arguments: ${{ github.event.inputs.configure-arguments }}
+      make-arguments: ${{ github.event.inputs.make-arguments }}
+      # It currently doesn't produce any bundles, but probably will do in
+      # the future.
+      bundle-suffix: "-static"
+    if: needs.prepare.outputs.linux-x64 == 'true'
+
+  build-linux-x64-static-libs:
+    name: linux-x64-static-libs
+    needs: prepare
+    uses: ./.github/workflows/build-linux.yml
+    with:
+      platform: linux-x64
+      make-target: 'static-libs-bundles'
+      # Only build static-libs-bundles for release builds.
+      # For debug builds, building static-libs often exceeds disk space.
+      debug-levels: '[ "release" ]'
+      gcc-major-version: '10'
+      configure-arguments: ${{ github.event.inputs.configure-arguments }}
+      make-arguments: ${{ github.event.inputs.make-arguments }}
+      # Upload static libs bundles separately to avoid interference with normal linux-x64 bundle.
+      # This bundle is not used by testing jobs, but downstreams use it to check that
+      # dependent projects, e.g. libgraal, builds fine.
+      bundle-suffix: "-static-libs"
+    if: needs.prepare.outputs.linux-x64-variants == 'true'
+
   build-linux-cross-compile:
     name: linux-cross-compile
     needs: prepare

.gitignore

@@ -22,3 +22,4 @@ NashornProfile.txt
 /.cache
 /.gdbinit
 /.lldbinit
+**/core.[0-9]*

CONTRIBUTING.md

@@ -1,3 +1,3 @@
 # Contributing to the JDK
 
-Please see the [OpenJDK Developers’ Guide](https://openjdk.org/guide/).
+Please see the [OpenJDK Developers' Guide](https://openjdk.org/guide/).

doc/building.html

@@ -586,7 +586,7 @@ <h2 id="native-compiler-toolchain-requirements">Native Compiler
 <tbody>
 <tr class="odd">
 <td>Linux</td>
-<td>gcc 13.2.0</td>
+<td>gcc 14.2.0</td>
 </tr>
 <tr class="even">
 <td>macOS</td>
@@ -604,7 +604,7 @@ <h3 id="gcc">gcc</h3>
 <p>The minimum accepted version of gcc is 10.0. Older versions will not
 be accepted by <code>configure</code>.</p>
 <p>The JDK is currently known to compile successfully with gcc version
-13.2 or newer.</p>
+14.2 or newer.</p>
 <p>In general, any version between these two should be usable.</p>
 <h3 id="clang">clang</h3>
 <p>The minimum accepted version of clang is 13. Older versions will not
@@ -1722,6 +1722,20 @@ <h4 id="building-for-musl">Building for musl</h4>
 --with-devkit=$DEVKIT \
 --with-sysroot=$SYSROOT</code></pre>
 <p>and run <code>make</code> normally.</p>
+<h4 id="building-for-windows-aarch64">Building for Windows AArch64</h4>
+<p>The Visual Studio Build Tools can be used for building the JDK
+without a full Visual Studio installation. To set up the Visual Studio
+2022 Build Tools on a Windows AArch64 machine for a native build, launch
+the installer as follows in a Windows command prompt:</p>
+<pre><code>vs_buildtools.exe --quiet --wait --norestart --nocache ^
+--installPath &quot;%ProgramFiles(x86)%\Microsoft Visual Studio\2022\BuildTools&quot; ^
+--add Microsoft.VisualStudio.Component.VC.CoreBuildTools ^
+--add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
+--add Microsoft.VisualStudio.Component.Windows11SDK.22621</code></pre>
+<p>To generate Windows AArch64 builds using Cygwin on a Windows x64
+machine, you must set the proper target platform by adding
+<code>--openjdk-target=aarch64-unknown-cygwin</code> to your configure
+command line.</p>
 <h2 id="build-performance">Build Performance</h2>
 <p>Building the JDK requires a lot of horsepower. Some of the build
 tools can be adjusted to utilize more or less of resources such as

doc/building.md

@@ -392,7 +392,7 @@ issues.
 
 | Operating system   | Toolchain version                           |
 | ------------------ | ------------------------------------------- |
-| Linux              | gcc 13.2.0                                  |
+| Linux              | gcc 14.2.0                                  |
 | macOS              | Apple Xcode 14.3.1 (using clang 14.0.3)     |
 | Windows            | Microsoft Visual Studio 2022 version 17.6.5 |
 
@@ -404,7 +404,7 @@ C, and C++14 for C++.
 The minimum accepted version of gcc is 10.0. Older versions will not be accepted
 by `configure`.
 
-The JDK is currently known to compile successfully with gcc version 13.2 or
+The JDK is currently known to compile successfully with gcc version 14.2 or
 newer.
 
 In general, any version between these two should be usable.
@@ -1457,6 +1457,24 @@ sh ./configure --with-jvm-variants=server \
 
 and run `make` normally.
 
+#### Building for Windows AArch64
+The Visual Studio Build Tools can be used for building the JDK without a full
+Visual Studio installation. To set up the Visual Studio 2022 Build Tools on a
+Windows AArch64 machine for a native build, launch the installer as follows
+in a Windows command prompt:
+
+```
+vs_buildtools.exe --quiet --wait --norestart --nocache ^
+--installPath "%ProgramFiles(x86)%\Microsoft Visual Studio\2022\BuildTools" ^
+--add Microsoft.VisualStudio.Component.VC.CoreBuildTools ^
+--add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
+--add Microsoft.VisualStudio.Component.Windows11SDK.22621
+```
+
+To generate Windows AArch64 builds using Cygwin on a Windows x64 machine,
+you must set the proper target platform by adding
+`--openjdk-target=aarch64-unknown-cygwin` to your configure command line.
+
 ## Build Performance
 
 Building the JDK requires a lot of horsepower. Some of the build tools can be

doc/hotspot-style.html

@@ -207,23 +207,38 @@ <h3 id="source-files">Source Files</h3>
 <ul>
 <li><p>All source files must have a globally unique basename. The build
 system depends on this uniqueness.</p></li>
+<li><p>Keep the include lines within a section alphabetically sorted by
+their lowercase value. If an include must be out of order for
+correctness, suffix with it a comment such as
+<code>// do not reorder</code>. Source code processing tools can also
+use this hint.</p></li>
+<li><p>Put conditional inclusions (<code>#if ...</code>) at the end of
+the section of HotSpot include lines. This also applies to
+macro-expanded includes of platform dependent files.</p></li>
+<li><p>Put system includes in a section after the HotSpot include lines
+with a blank line separating the two sections.</p></li>
 <li><p>Do not put non-trivial function implementations in .hpp files. If
 the implementation depends on other .hpp files, put it in a .cpp or a
 .inline.hpp file.</p></li>
 <li><p>.inline.hpp files should only be included in .cpp or .inline.hpp
 files.</p></li>
 <li><p>All .inline.hpp files should include their corresponding .hpp
-file as the first include line. Declarations needed by other files
-should be put in the .hpp file, and not in the .inline.hpp file. This
-rule exists to resolve problems with circular dependencies between
-.inline.hpp files.</p></li>
+file as the first include line with a blank line separating it from the
+rest of the include lines. Declarations needed by other files should be
+put in the .hpp file, and not in the .inline.hpp file. This rule exists
+to resolve problems with circular dependencies between .inline.hpp
+files.</p></li>
+<li><p>Do not include a .hpp file if the corresponding .inline.hpp file
+is included.</p></li>
+<li><p>Use include guards for .hpp and .inline.hpp files. The name of
+the defined guard should be derived from the full search path of the
+file relative to the hotspot source directory. The guard should be all
+upper case with all paths separators and periods replaced by
+underscores.</p></li>
 <li><p>Some build configurations use precompiled headers to speed up the
 build times. The precompiled headers are included in the precompiled.hpp
 file. Note that precompiled.hpp is just a build time optimization, so
 don't rely on it to resolve include problems.</p></li>
-<li><p>Keep the include lines alphabetically sorted.</p></li>
-<li><p>Put conditional inclusions (<code>#if ...</code>) at the end of
-the include list.</p></li>
 </ul>
 <h3 id="jtreg-tests">JTReg Tests</h3>
 <ul>

doc/hotspot-style.md

@@ -135,9 +135,21 @@ change should be done with a "setter" accessor matched to the simple
 
 ### Source Files
 
-* All source files must have a globally unique basename.  The build
+* All source files must have a globally unique basename. The build
 system depends on this uniqueness.
 
+* Keep the include lines within a section alphabetically sorted by their
+lowercase value. If an include must be out of order for correctness,
+suffix with it a comment such as `// do not reorder`. Source code
+processing tools can also use this hint.
+
+* Put conditional inclusions (`#if ...`) at the end of the section of HotSpot
+include lines. This also applies to macro-expanded includes of platform
+dependent files.
+
+* Put system includes in a section after the HotSpot include lines with a blank
+line separating the two sections.
+
 * Do not put non-trivial function implementations in .hpp files. If
 the implementation depends on other .hpp files, put it in a .cpp or
 a .inline.hpp file.
@@ -146,19 +158,23 @@ a .inline.hpp file.
 files.
 
 * All .inline.hpp files should include their corresponding .hpp file as
-the first include line. Declarations needed by other files should be put
-in the .hpp file, and not in the .inline.hpp file. This rule exists to
-resolve problems with circular dependencies between .inline.hpp files.
+the first include line with a blank line separating it from the rest of the
+include lines. Declarations needed by other files should be put in the .hpp
+file, and not in the .inline.hpp file. This rule exists to resolve problems
+with circular dependencies between .inline.hpp files.
+
+* Do not include a .hpp file if the corresponding .inline.hpp file is included.
+
+* Use include guards for .hpp and .inline.hpp files. The name of the defined
+guard should be derived from the full search path of the file relative to the
+hotspot source directory. The guard should be all upper case with all paths
+separators and periods replaced by underscores.
 
 * Some build configurations use precompiled headers to speed up the
 build times. The precompiled headers are included in the precompiled.hpp
 file. Note that precompiled.hpp is just a build time optimization, so
 don't rely on it to resolve include problems.
 
-* Keep the include lines alphabetically sorted.
-
-* Put conditional inclusions (`#if ...`) at the end of the include list.
-
 ### JTReg Tests
 
 * JTReg tests should have meaningful names.

doc/hotspot-unit-tests.md

@@ -106,7 +106,7 @@ Prefer having checks inside test code.
 
 Not only does having test logic outside, e.g. verification method,
 depending on asserts in product code contradict with several items
-above but also decreases test’s readability and stability. It is much
+above but also decreases test's readability and stability. It is much
 easier to understand that a test is testing when all testing logic is
 located inside a test or nearby in shared test libraries. As a rule of
 thumb, the closer a check to a test, the better.
@@ -119,7 +119,7 @@ Prefer `EXPECT` over `ASSERT` if possible.
 
 This is related to the [informativeness](#informativeness) property of
 tests, information for other checks can help to better localize a
-defect’s root-cause. One should use `ASSERT` if it is impossible to
+defect's root-cause. One should use `ASSERT` if it is impossible to
 continue test execution or if it does not make much sense. Later in
 the text, `EXPECT` forms will be used to refer to both
 `ASSERT/EXPECT`.
@@ -160,7 +160,7 @@ value of the difference between `v1` and `v2` is not greater than `eps`.
 
 Use string special macros for C strings comparisons.
 
-`EXPECT_EQ` just compares pointers’ values, which is hardly what one
+`EXPECT_EQ` just compares pointers' values, which is hardly what one
 wants comparing C strings. GoogleTest provides `EXPECT_STREQ` and
 `EXPECT_STRNE` macros to compare C string contents. There are also
 case-insensitive versions `EXPECT_STRCASEEQ`, `EXPECT_STRCASENE`.
@@ -226,7 +226,7 @@ subsystem, etc.
 
 This naming scheme helps to find tests, filter them and simplifies
 test failure analysis. For example, class `Foo` - test group `Foo`,
-compiler logging subsystem - test group `CompilerLogging`, G1 GC — test
+compiler logging subsystem - test group `CompilerLogging`, G1 GC - test
 group `G1GC`, and so forth.
 
 ### Filename
@@ -287,7 +287,7 @@ Fixture classes should be named after tested classes, subsystems, etc
 
 All test purpose friends should have either `Test` or `Testable` suffix.
 
-It greatly simplifies understanding of friendship’s purpose and allows
+It greatly simplifies understanding of friendship's purpose and allows
 statically check that private members are not exposed unexpectedly.
 Having `FooTest` as a friend of `Foo` without any comments will be
 understood as a necessary evil to get testability.
@@ -397,7 +397,7 @@ and filter out inapplicable tests.
 Restore changed flags.
 
 It is quite common for tests to configure JVM in a certain way
-changing flags’ values. GoogleTest provides two ways to set up
+changing flags' values. GoogleTest provides two ways to set up
 environment before a test and restore it afterward: using either
 constructor and destructor or `SetUp` and `TearDown` functions. Both ways
 require to use a test fixture class, which sometimes is too wordy. The
@@ -406,7 +406,7 @@ be used in such cases to restore/set values.
 
 Caveats:
 
-* Changing a flag’s value could break the invariants between flags' values and hence could lead to unexpected/unsupported JVM state.
+* Changing a flag's value could break the invariants between flags' values and hence could lead to unexpected/unsupported JVM state.
 
 * `FLAG_SET_*` macros can change more than one flag (in order to
 maintain invariants) so it is hard to predict what flags will be