Merge pull request #70 from openjdk/master

Merge

Author: azuev-java

.editorconfig

@@ -0,0 +1,11 @@
+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
+
+[src/hotspot/**.{cpp,hpp,h}]
+indent_style = space
+indent_size = 2

.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
 

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

@@ -376,7 +376,7 @@ <h2 id="operating-system-requirements">Operating System
 </tr>
 <tr class="odd">
 <td>macOS</td>
-<td>macOS 13.x (Ventura)</td>
+<td>macOS 14.x</td>
 </tr>
 <tr class="even">
 <td>Windows</td>
@@ -513,8 +513,8 @@ <h3 id="macos">macOS</h3>
 a continuously updated machine running macOS. See the section on <a
 href="#apple-xcode">Apple Xcode</a> on some strategies to deal with
 this.</p>
-<p>It is recommended that you use at least macOS 13 (Ventura) and Xcode
-14, but earlier versions may also work.</p>
+<p>It is recommended that you use at least macOS 14 and Xcode 15.4, but
+earlier versions may also work.</p>
 <p>The standard macOS environment contains the basic tooling needed to
 build, but for external libraries a package manager is recommended. The
 JDK uses <a href="https://brew.sh/">homebrew</a> in the examples, but
@@ -586,15 +586,15 @@ <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>
-<td>Apple Xcode 14.3.1 (using clang 14.0.3)</td>
+<td>Apple Xcode 15.4 (using clang 15.0.0)</td>
 </tr>
 <tr class="odd">
 <td>Windows</td>
-<td>Microsoft Visual Studio 2022 version 17.6.5</td>
+<td>Microsoft Visual Studio 2022 version 17.13.2</td>
 </tr>
 </tbody>
 </table>
@@ -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

@@ -175,7 +175,7 @@ time of writing.
 | ----------------- | ---------------------------------- |
 | Linux/x64         | Oracle Enterprise Linux 6.4 / 8.x  |
 | Linux/aarch64     | Oracle Enterprise Linux 7.6 / 8.x  |
-| macOS             | macOS 13.x (Ventura)               |
+| macOS             | macOS 14.x                         |
 | Windows           | Windows Server 2016                |
 
 The double version numbers for Linux are due to the hybrid model used at
@@ -327,7 +327,7 @@ difficult for a project such as the JDK to keep pace with a continuously
 updated machine running macOS. See the section on [Apple Xcode](#apple-xcode)
 on some strategies to deal with this.
 
-It is recommended that you use at least macOS 13 (Ventura) and Xcode 14, but
+It is recommended that you use at least macOS 14 and Xcode 15.4, but
 earlier versions may also work.
 
 The standard macOS environment contains the basic tooling needed to build, but
@@ -390,11 +390,11 @@ possible to compile the JDK with both older and newer versions, but the closer
 you stay to this list, the more likely you are to compile successfully without
 issues.
 
-| Operating system   | Toolchain version                           |
-| ------------------ | ------------------------------------------- |
-| Linux              | gcc 13.2.0                                  |
-| macOS              | Apple Xcode 14.3.1 (using clang 14.0.3)     |
-| Windows            | Microsoft Visual Studio 2022 version 17.6.5 |
+| Operating system   | Toolchain version                            |
+| ------------------ | -------------------------------------------- |
+| Linux              | gcc 14.2.0                                   |
+| macOS              | Apple Xcode 15.4 (using clang 15.0.0)       |
+| Windows            | Microsoft Visual Studio 2022 version 17.13.2 |
 
 All compilers are expected to be able to handle the C11 language standard for
 C, and C++14 for C++.
@@ -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,27 +207,34 @@ <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.</p></li>
-<li><p>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.</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>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>
+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 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>All .inline.hpp files should include their corresponding .hpp
+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

doc/hotspot-style.md

@@ -138,7 +138,10 @@ change should be done with a "setter" accessor matched to the simple
 * 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.
+* 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

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

doc/testing.html

@@ -411,6 +411,13 @@ <h4 id="jcov">JCOV</h4>
 special target <code>jcov-test</code> instead of <code>test</code>, e.g.
 <code>make jcov-test TEST=jdk_lang</code>. This will make sure the JCov
 image is built, and that JCov reporting is enabled.</p>
+<p>To include JCov coverage for just a subset of all modules, you can
+use the <code>--with-jcov-modules</code> arguments to
+<code>configure</code>, e.g.
+<code>--with-jcov-modules=jdk.compiler,java.desktop</code>.</p>
+<p>For more fine-grained control, you can pass arbitrary filters to JCov
+using <code>--with-jcov-filters</code>, and you can specify a specific
+JDK to instrument using <code>--with-jcov-input-jdk</code>.</p>
 <p>The JCov report is stored in
 <code>build/$BUILD/test-results/jcov-output/report</code>.</p>
 <p>Please note that running with JCov reporting can be very memory

doc/testing.md

@@ -345,6 +345,14 @@ The simplest way to run tests with JCov coverage report is to use the special
 target `jcov-test` instead of `test`, e.g. `make jcov-test TEST=jdk_lang`. This
 will make sure the JCov image is built, and that JCov reporting is enabled.
 
+To include JCov coverage for just a subset of all modules, you can use the
+`--with-jcov-modules` arguments to `configure`, e.g.
+`--with-jcov-modules=jdk.compiler,java.desktop`.
+
+For more fine-grained control, you can pass arbitrary filters to JCov using
+`--with-jcov-filters`, and you can specify a specific JDK to instrument
+using `--with-jcov-input-jdk`.
+
 The JCov report is stored in `build/$BUILD/test-results/jcov-output/report`.
 
 Please note that running with JCov reporting can be very memory intensive.