Skip to content

Commit cd3bd58

Browse files
TheRealMDoerrTheRealMDoerr
committed
Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
2 parents dfc6aa5 + ea86a20 commit cd3bd58

File tree

1,239 files changed

+28219
-18213
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

1,239 files changed

+28219
-18213
lines changed

‎.github/workflows/main.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -310,7 +310,7 @@ jobs:
310310
uses: ./.github/workflows/build-windows.yml
311311
with:
312312
platform: windows-x64
313-
msvc-toolset-version: '14.43'
313+
msvc-toolset-version: '14.44'
314314
msvc-toolset-architecture: 'x86.x64'
315315
configure-arguments: ${{ github.event.inputs.configure-arguments }}
316316
make-arguments: ${{ github.event.inputs.make-arguments }}
@@ -322,7 +322,7 @@ jobs:
322322
uses: ./.github/workflows/build-windows.yml
323323
with:
324324
platform: windows-aarch64
325-
msvc-toolset-version: '14.43'
325+
msvc-toolset-version: '14.44'
326326
msvc-toolset-architecture: 'arm64'
327327
make-target: 'hotspot'
328328
extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin'

‎doc/hotspot-style.html‎

Lines changed: 83 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -77,13 +77,17 @@ <h1 class="title">HotSpot Coding Style</h1>
7777
<li><a href="#thread_local" id="toc-thread_local">thread_local</a></li>
7878
<li><a href="#nullptr" id="toc-nullptr">nullptr</a></li>
7979
<li><a href="#atomic" id="toc-atomic">&lt;atomic&gt;</a></li>
80+
<li><a href="#initializing-variables-with-static-storage-duration"
81+
id="toc-initializing-variables-with-static-storage-duration">Initializing
82+
variables with static storage duration</a></li>
8083
<li><a href="#uniform-initialization"
8184
id="toc-uniform-initialization">Uniform Initialization</a></li>
8285
<li><a href="#local-function-objects"
8386
id="toc-local-function-objects">Local Function Objects</a></li>
8487
<li><a href="#inheriting-constructors"
8588
id="toc-inheriting-constructors">Inheriting constructors</a></li>
8689
<li><a href="#attributes" id="toc-attributes">Attributes</a></li>
90+
<li><a href="#noexcept" id="toc-noexcept">noexcept</a></li>
8791
<li><a href="#additional-permitted-features"
8892
id="toc-additional-permitted-features">Additional Permitted
8993
Features</a></li>
@@ -791,6 +795,33 @@ <h3 id="atomic">&lt;atomic&gt;</h3>
791795
"conservative" memory ordering, which may differ from (may be stronger
792796
than) sequentially consistent. There are algorithms in HotSpot that are
793797
believed to rely on that ordering.</p>
798+
<h3
799+
id="initializing-variables-with-static-storage-duration">Initializing
800+
variables with static storage duration</h3>
801+
<p>Variables with static storage duration and <em>dynamic
802+
initialization</em> <a
803+
href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf">C++14
804+
3.6.2</a>). should be avoided, unless an implementation is permitted to
805+
perform the initialization as a static initialization. The order in
806+
which dynamic initializations occur is incompletely specified.
807+
Initialization order problems can be difficult to deal with and lead to
808+
surprises.</p>
809+
<p>Variables with static storage duration and non-trivial destructors
810+
should be avoided. HotSpot doesn't generally try to cleanup on exit, and
811+
running destructors at exit can lead to problems.</p>
812+
<p>Some of the approaches used in HotSpot to avoid dynamic
813+
initialization include:</p>
814+
<ul>
815+
<li><p>Use the <code>Deferred&lt;T&gt;</code> class template. Add a call
816+
to its initialization function at an appropriate place during VM
817+
initialization. The underlying object is never destroyed.</p></li>
818+
<li><p>For objects of class type, use a variable whose value is a
819+
pointer to the class, initialized to <code>nullptr</code>. Provide an
820+
initialization function that sets the variable to a dynamically
821+
allocated object. Add a call to that function at an appropriate place
822+
during VM initialization. Such objects are usually never
823+
destroyed.</p></li>
824+
</ul>
794825
<h3 id="uniform-initialization">Uniform Initialization</h3>
795826
<p>The use of <em>uniform initialization</em> (<a
796827
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm">n2672</a>),
@@ -1110,6 +1141,58 @@ <h3 id="attributes">Attributes</h3>
11101141
<code>memory_order_consume</code>.</li>
11111142
<li><code>[[deprecated]]</code> - Not relevant in HotSpot code.</li>
11121143
</ul>
1144+
<h3 id="noexcept">noexcept</h3>
1145+
<p>Use of <code>noexcept</code> exception specifications (<a
1146+
href="http://wg21.link/n3050">n3050</a>) are permitted with restrictions
1147+
described below.</p>
1148+
<ul>
1149+
<li>Only the argument-less form of <code>noexcept</code> exception
1150+
specifications are permitted.</li>
1151+
<li>Allocation functions that may return <code>nullptr</code> to
1152+
indicate allocation failure must be declared <code>noexcept</code>.</li>
1153+
<li>All other uses of <code>noexcept</code> exception specifications are
1154+
forbidden.</li>
1155+
<li><code>noexcept</code> expressions are forbidden.</li>
1156+
<li>Dynamic exception specifications are forbidden.</li>
1157+
</ul>
1158+
<p>HotSpot is built with exceptions disabled, e.g. compile with
1159+
<code>-fno-exceptions</code> (gcc, clang) or no <code>/EH</code> option
1160+
(MSVC++). So why do we need to consider <code>noexcept</code> at all?
1161+
It's because <code>noexcept</code> exception specifications serve two
1162+
distinct purposes.</p>
1163+
<p>The first is to allow the compiler to avoid generating code or data
1164+
in support of exceptions being thrown by a function. But this is
1165+
unnecessary, because exceptions are disabled.</p>
1166+
<p>The second is to allow the compiler and library code to choose
1167+
different algorithms, depending on whether some function may throw
1168+
exceptions. This is only relevant to a certain set of functions.</p>
1169+
<ul>
1170+
<li><p>Some allocation functions (<code>operator new</code> and
1171+
<code>operator new[]</code>) return <code>nullptr</code> to indicate
1172+
allocation failure. If a <code>new</code> expression calls such an
1173+
allocation function, it must check for and handle that possibility.
1174+
Declaring such a function <code>noexcept</code> informs the compiler
1175+
that <code>nullptr</code> is a possible result. If an allocation
1176+
function is not declared <code>noexcept</code> then the compiler may
1177+
elide that checking and handling for a <code>new</code> expression
1178+
calling that function.</p></li>
1179+
<li><p>Certain Standard Library facilities (notably containers) provide
1180+
different guarantees for some operations (and may choose different
1181+
algorithms to implement those operations), depending on whether certain
1182+
functions (constructors, copy/move operations, swap) are nothrow or not.
1183+
They detect this using type traits that test whether a function is
1184+
declared <code>noexcept</code>. This can have a significant performance
1185+
impact if, for example, copying is chosen over a potentially throwing
1186+
move. But this isn't relevant, since HotSpot forbids the use of most
1187+
Standard Library facilities.</p></li>
1188+
</ul>
1189+
<p>HotSpot code can assume no exceptions will ever be thrown, even from
1190+
functions not declared <code>noexcept</code>. So HotSpot code doesn't
1191+
ever need to check, either with conditional exception specifications or
1192+
with <code>noexcept</code> expressions.</p>
1193+
<p>Dynamic exception specifications were deprecated in C++11. C++17
1194+
removed all but <code>throw()</code>, with that remaining a deprecated
1195+
equivalent to <code>noexcept</code>.</p>
11131196
<h3 id="additional-permitted-features">Additional Permitted
11141197
Features</h3>
11151198
<ul>
@@ -1198,12 +1281,6 @@ <h3 id="excluded-features">Excluded Features</h3>
11981281
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html">n2179</a>)
11991282
— HotSpot does not permit the use of exceptions, so this feature isn't
12001283
useful.</p></li>
1201-
<li><p>Avoid non-local variables with non-constexpr initialization. In
1202-
particular, avoid variables with types requiring non-trivial
1203-
initialization or destruction. Initialization order problems can be
1204-
difficult to deal with and lead to surprises, as can destruction
1205-
ordering. HotSpot doesn't generally try to cleanup on exit, and running
1206-
destructors at exit can also lead to problems.</p></li>
12071284
<li><p>Avoid most operator overloading, preferring named functions. When
12081285
operator overloading is used, ensure the semantics conform to the normal
12091286
expected behavior of the operation.</p></li>

‎doc/hotspot-style.md‎

Lines changed: 77 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -770,6 +770,32 @@ ordering, which may differ from (may be stronger than) sequentially
770770
consistent. There are algorithms in HotSpot that are believed to rely
771771
on that ordering.
772772

773+
### Initializing variables with static storage duration
774+
775+
Variables with static storage duration and _dynamic initialization_
776+
[C++14 3.6.2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)).
777+
should be avoided, unless an implementation is permitted to perform the
778+
initialization as a static initialization. The order in which dynamic
779+
initializations occur is incompletely specified. Initialization order
780+
problems can be difficult to deal with and lead to surprises.
781+
782+
Variables with static storage duration and non-trivial destructors should be
783+
avoided. HotSpot doesn't generally try to cleanup on exit, and running
784+
destructors at exit can lead to problems.
785+
786+
Some of the approaches used in HotSpot to avoid dynamic initialization
787+
include:
788+
789+
* Use the `Deferred<T>` class template. Add a call to its initialization
790+
function at an appropriate place during VM initialization. The underlying
791+
object is never destroyed.
792+
793+
* For objects of class type, use a variable whose value is a pointer to the
794+
class, initialized to `nullptr`. Provide an initialization function that sets
795+
the variable to a dynamically allocated object. Add a call to that function at
796+
an appropriate place during VM initialization. Such objects are usually never
797+
destroyed.
798+
773799
### Uniform Initialization
774800

775801
The use of _uniform initialization_
@@ -1104,6 +1130,57 @@ The following attributes are expressly forbidden:
11041130
* `[[carries_dependency]]` - Related to `memory_order_consume`.
11051131
* `[[deprecated]]` - Not relevant in HotSpot code.
11061132
1133+
### noexcept
1134+
1135+
Use of `noexcept` exception specifications
1136+
([n3050](http://wg21.link/n3050))
1137+
are permitted with restrictions described below.
1138+
1139+
* Only the argument-less form of `noexcept` exception specifications are
1140+
permitted.
1141+
* Allocation functions that may return `nullptr` to indicate allocation
1142+
failure must be declared `noexcept`.
1143+
* All other uses of `noexcept` exception specifications are forbidden.
1144+
* `noexcept` expressions are forbidden.
1145+
* Dynamic exception specifications are forbidden.
1146+
1147+
HotSpot is built with exceptions disabled, e.g. compile with `-fno-exceptions`
1148+
(gcc, clang) or no `/EH` option (MSVC++). So why do we need to consider
1149+
`noexcept` at all? It's because `noexcept` exception specifications serve two
1150+
distinct purposes.
1151+
1152+
The first is to allow the compiler to avoid generating code or data in support
1153+
of exceptions being thrown by a function. But this is unnecessary, because
1154+
exceptions are disabled.
1155+
1156+
The second is to allow the compiler and library code to choose different
1157+
algorithms, depending on whether some function may throw exceptions. This is
1158+
only relevant to a certain set of functions.
1159+
1160+
* Some allocation functions (`operator new` and `operator new[]`) return
1161+
`nullptr` to indicate allocation failure. If a `new` expression calls such an
1162+
allocation function, it must check for and handle that possibility. Declaring
1163+
such a function `noexcept` informs the compiler that `nullptr` is a possible
1164+
result. If an allocation function is not declared `noexcept` then the compiler
1165+
may elide that checking and handling for a `new` expression calling that
1166+
function.
1167+
1168+
* Certain Standard Library facilities (notably containers) provide different
1169+
guarantees for some operations (and may choose different algorithms to
1170+
implement those operations), depending on whether certain functions
1171+
(constructors, copy/move operations, swap) are nothrow or not. They detect
1172+
this using type traits that test whether a function is declared `noexcept`.
1173+
This can have a significant performance impact if, for example, copying is
1174+
chosen over a potentially throwing move. But this isn't relevant, since
1175+
HotSpot forbids the use of most Standard Library facilities.
1176+
1177+
HotSpot code can assume no exceptions will ever be thrown, even from functions
1178+
not declared `noexcept`. So HotSpot code doesn't ever need to check, either
1179+
with conditional exception specifications or with `noexcept` expressions.
1180+
1181+
Dynamic exception specifications were deprecated in C++11. C++17 removed all
1182+
but `throw()`, with that remaining a deprecated equivalent to `noexcept`.
1183+
11071184
### Additional Permitted Features
11081185
11091186
* `alignof`
@@ -1199,13 +1276,6 @@ namespace std;` to avoid needing to qualify Standard Library names.
11991276
([n2179](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html)) &mdash;
12001277
HotSpot does not permit the use of exceptions, so this feature isn't useful.
12011278
1202-
* Avoid non-local variables with non-constexpr initialization.
1203-
In particular, avoid variables with types requiring non-trivial
1204-
initialization or destruction. Initialization order problems can be
1205-
difficult to deal with and lead to surprises, as can destruction
1206-
ordering. HotSpot doesn't generally try to cleanup on exit, and
1207-
running destructors at exit can also lead to problems.
1208-
12091279
* Avoid most operator overloading, preferring named functions. When
12101280
operator overloading is used, ensure the semantics conform to the
12111281
normal expected behavior of the operation.

‎make/autoconf/configure‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
#!/bin/bash
22
#
3-
# Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved.
3+
# Copyright (c) 2012, 2025, Oracle and/or its affiliates. All rights reserved.
44
# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
55
#
66
# This code is free software; you can redistribute it and/or modify it
@@ -366,7 +366,7 @@ EOT
366366
367367
# Print additional help, e.g. a list of toolchains and JVM features.
368368
# This must be done by the autoconf script.
369-
( CONFIGURE_PRINT_ADDITIONAL_HELP=true . $generated_script PRINTF=printf )
369+
( CONFIGURE_PRINT_ADDITIONAL_HELP=true . $generated_script PRINTF=printf ECHO=echo )
370370
371371
cat <<EOT
372372

‎make/autoconf/lib-tests.m4‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@
2828
################################################################################
2929

3030
# Minimum supported versions
31-
JTREG_MINIMUM_VERSION=7.5.1
31+
JTREG_MINIMUM_VERSION=7.5.2
3232
GTEST_MINIMUM_VERSION=1.14.0
3333

3434
################################################################################

‎make/conf/github-actions.conf‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@
2626
# Versions and download locations for dependencies used by GitHub Actions (GHA)
2727

2828
GTEST_VERSION=1.14.0
29-
JTREG_VERSION=7.5.1+1
29+
JTREG_VERSION=7.5.2+1
3030

3131
LINUX_X64_BOOT_JDK_EXT=tar.gz
3232
LINUX_X64_BOOT_JDK_URL=https://download.java.net/java/GA/jdk24/1f9ff9062db4449d8ca828c504ffae90/36/GPL/openjdk-24_linux-x64_bin.tar.gz

‎make/conf/jib-profiles.js‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1174,9 +1174,9 @@ var getJibProfilesDependencies = function (input, common) {
11741174
jtreg: {
11751175
server: "jpg",
11761176
product: "jtreg",
1177-
version: "7.5.1",
1177+
version: "7.5.2",
11781178
build_number: "1",
1179-
file: "bundles/jtreg-7.5.1+1.zip",
1179+
file: "bundles/jtreg-7.5.2+1.zip",
11801180
environment_name: "JT_HOME",
11811181
environment_path: input.get("jtreg", "home_path") + "/bin",
11821182
configure_args: "--with-jtreg=" + input.get("jtreg", "home_path"),
@@ -1192,8 +1192,8 @@ var getJibProfilesDependencies = function (input, common) {
11921192
server: "jpg",
11931193
product: "jcov",
11941194
version: "3.0",
1195-
build_number: "1",
1196-
file: "bundles/jcov-3.0+1.zip",
1195+
build_number: "3",
1196+
file: "bundles/jcov-3.0+3.zip",
11971197
environment_name: "JCOV_HOME",
11981198
},
11991199

‎make/data/asan/asan_default_options.c‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -67,6 +67,8 @@ ATTRIBUTE_DEFAULT_VISIBILITY ATTRIBUTE_USED const char* CDECL __asan_default_opt
6767
#endif
6868
"print_suppressions=0,"
6969
"handle_segv=0,"
70+
// A lot of libjsig related tests fail because of the link order check; so better avoid it
71+
"verify_asan_link_order=0,"
7072
// See https://github.com/google/sanitizers/issues/1322. Hopefully this is resolved
7173
// at some point and we can remove this option.
7274
"intercept_tls_get_addr=0";

‎make/data/ubsan/ubsan_default_options.c‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,5 +62,8 @@
6262
// thread so it is easier to track down. You can override these options by setting the environment
6363
// variable UBSAN_OPTIONS.
6464
ATTRIBUTE_DEFAULT_VISIBILITY ATTRIBUTE_USED const char* __ubsan_default_options() {
65-
return "halt_on_error=1,print_stacktrace=1" _LLVM_SYMBOLIZER(LLVM_SYMBOLIZER);
65+
return "halt_on_error=1,"
66+
"handle_segv=0,"
67+
"handle_sigbus=0,"
68+
"print_stacktrace=1" _LLVM_SYMBOLIZER(LLVM_SYMBOLIZER);
6669
}

‎make/devkit/createWindowsDevkit.sh‎

Lines changed: 30 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -64,6 +64,30 @@ IS_WSL=`echo $UNAME_RELEASE | grep Microsoft`
6464
IS_MSYS=`echo $UNAME_OS | grep -i Msys`
6565
MSYS2_ARG_CONV_EXCL="*" # make "cmd.exe /c" work for msys2
6666
CMD_EXE="cmd.exe /c"
67+
68+
# Detect host architecture to determine devkit platform support
69+
# Note: The devkit always includes x86, x64, and aarch64 libraries and tools
70+
# The difference is in toolchain capabilities:
71+
# - On x64|AMD64 hosts: aarch64 tools are cross-compilation tools (Hostx64/arm64)
72+
# - On aarch64|ARMv8 hosts: aarch64 tools are native tools (Hostarm64/arm64)
73+
HOST_ARCH=`echo $PROCESSOR_IDENTIFIER`
74+
case $HOST_ARCH in
75+
AMD64)
76+
echo "Running on x64 host - generating devkit with native x86/x64 tools and cross-compiled aarch64 tools."
77+
echo "For native aarch64 compilation tools, run this script on a Windows/aarch64 machine."
78+
SUPPORTED_PLATFORMS="x86, x64 (native) and aarch64 (cross-compiled)"
79+
;;
80+
ARMv8)
81+
echo "Running on aarch64 host - generating devkit with native tools for all platforms (x86, x64, aarch64)."
82+
SUPPORTED_PLATFORMS="x86, x64, and aarch64 (all native)"
83+
;;
84+
*)
85+
echo "Unknown host architecture: $HOST_ARCH"
86+
echo "Proceeding with devkit generation - toolchain capabilities may vary."
87+
SUPPORTED_PLATFORMS="x86, x64, and aarch64"
88+
;;
89+
esac
90+
6791
if test "x$IS_CYGWIN" != "x"; then
6892
BUILD_ENV="cygwin"
6993
elif test "x$IS_MSYS" != "x"; then
@@ -139,6 +163,7 @@ DEVKIT_ROOT="${BUILD_DIR}/VS${VS_VERSION}-${VS_VERSION_SP}-devkit"
139163
DEVKIT_BUNDLE="${DEVKIT_ROOT}.tar.gz"
140164

141165
echo "Creating devkit in $DEVKIT_ROOT"
166+
echo "Platform support: $SUPPORTED_PLATFORMS"
142167

143168
MSVCR_DLL=${MSVC_CRT_DIR}/vcruntime${VS_DLL_VERSION}.dll
144169
VCRUNTIME_1_DLL=${MSVC_CRT_DIR}/vcruntime${VS_DLL_VERSION}_1.dll
@@ -156,7 +181,11 @@ REDIST_SUBDIR="VC/Redist/MSVC/$REDIST_VERSION"
156181
echo "Copying VC..."
157182
rm -rf $DEVKIT_ROOT/VC
158183
mkdir -p $DEVKIT_ROOT/VC/bin
159-
cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/
184+
if [ -d "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" ]; then
185+
cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostarm64/arm64" $DEVKIT_ROOT/VC/bin/
186+
else
187+
cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/arm64" $DEVKIT_ROOT/VC/bin/
188+
fi
160189
cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx64/x64" $DEVKIT_ROOT/VC/bin/
161190
cp -r "$VS_INSTALL_DIR/${VC_SUBDIR}/bin/Hostx86/x86" $DEVKIT_ROOT/VC/bin/
162191
mkdir -p $DEVKIT_ROOT/VC/lib

0 commit comments

Comments
 (0)