Merge jdk

Merge jdk-26+4

Author: David Simms

.github/workflows/main.yml

@@ -310,7 +310,7 @@ jobs:
     uses: ./.github/workflows/build-windows.yml
     with:
       platform: windows-x64
-      msvc-toolset-version: '14.43'
+      msvc-toolset-version: '14.44'
       msvc-toolset-architecture: 'x86.x64'
       configure-arguments: ${{ github.event.inputs.configure-arguments }}
       make-arguments: ${{ github.event.inputs.make-arguments }}
@@ -322,7 +322,7 @@ jobs:
     uses: ./.github/workflows/build-windows.yml
     with:
       platform: windows-aarch64
-      msvc-toolset-version: '14.43'
+      msvc-toolset-version: '14.44'
       msvc-toolset-architecture: 'arm64'
       make-target: 'hotspot'
       extra-conf-options: '--openjdk-target=aarch64-unknown-cygwin'

doc/hotspot-style.html

@@ -77,13 +77,17 @@ <h1 class="title">HotSpot Coding Style</h1>
 <li><a href="#thread_local" id="toc-thread_local">thread_local</a></li>
 <li><a href="#nullptr" id="toc-nullptr">nullptr</a></li>
 <li><a href="#atomic" id="toc-atomic">&lt;atomic&gt;</a></li>
+<li><a href="#initializing-variables-with-static-storage-duration"
+id="toc-initializing-variables-with-static-storage-duration">Initializing
+variables with static storage duration</a></li>
 <li><a href="#uniform-initialization"
 id="toc-uniform-initialization">Uniform Initialization</a></li>
 <li><a href="#local-function-objects"
 id="toc-local-function-objects">Local Function Objects</a></li>
 <li><a href="#inheriting-constructors"
 id="toc-inheriting-constructors">Inheriting constructors</a></li>
 <li><a href="#attributes" id="toc-attributes">Attributes</a></li>
+<li><a href="#noexcept" id="toc-noexcept">noexcept</a></li>
 <li><a href="#additional-permitted-features"
 id="toc-additional-permitted-features">Additional Permitted
 Features</a></li>
@@ -791,6 +795,33 @@ <h3 id="atomic">&lt;atomic&gt;</h3>
 "conservative" memory ordering, which may differ from (may be stronger
 than) sequentially consistent. There are algorithms in HotSpot that are
 believed to rely on that ordering.</p>
+<h3
+id="initializing-variables-with-static-storage-duration">Initializing
+variables with static storage duration</h3>
+<p>Variables with static storage duration and <em>dynamic
+initialization</em> <a
+href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf">C++14
+3.6.2</a>). should be avoided, unless an implementation is permitted to
+perform the initialization as a static initialization. The order in
+which dynamic initializations occur is incompletely specified.
+Initialization order problems can be difficult to deal with and lead to
+surprises.</p>
+<p>Variables with static storage duration and non-trivial destructors
+should be avoided. HotSpot doesn't generally try to cleanup on exit, and
+running destructors at exit can lead to problems.</p>
+<p>Some of the approaches used in HotSpot to avoid dynamic
+initialization include:</p>
+<ul>
+<li><p>Use the <code>Deferred&lt;T&gt;</code> class template. Add a call
+to its initialization function at an appropriate place during VM
+initialization. The underlying object is never destroyed.</p></li>
+<li><p>For objects of class type, use a variable whose value is a
+pointer to the class, initialized to <code>nullptr</code>. Provide an
+initialization function that sets the variable to a dynamically
+allocated object. Add a call to that function at an appropriate place
+during VM initialization. Such objects are usually never
+destroyed.</p></li>
+</ul>
 <h3 id="uniform-initialization">Uniform Initialization</h3>
 <p>The use of <em>uniform initialization</em> (<a
 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>
 <code>memory_order_consume</code>.</li>
 <li><code>[[deprecated]]</code> - Not relevant in HotSpot code.</li>
 </ul>
+<h3 id="noexcept">noexcept</h3>
+<p>Use of <code>noexcept</code> exception specifications (<a
+href="http://wg21.link/n3050">n3050</a>) are permitted with restrictions
+described below.</p>
+<ul>
+<li>Only the argument-less form of <code>noexcept</code> exception
+specifications are permitted.</li>
+<li>Allocation functions that may return <code>nullptr</code> to
+indicate allocation failure must be declared <code>noexcept</code>.</li>
+<li>All other uses of <code>noexcept</code> exception specifications are
+forbidden.</li>
+<li><code>noexcept</code> expressions are forbidden.</li>
+<li>Dynamic exception specifications are forbidden.</li>
+</ul>
+<p>HotSpot is built with exceptions disabled, e.g. compile with
+<code>-fno-exceptions</code> (gcc, clang) or no <code>/EH</code> option
+(MSVC++). So why do we need to consider <code>noexcept</code> at all?
+It's because <code>noexcept</code> exception specifications serve two
+distinct purposes.</p>
+<p>The first is to allow the compiler to avoid generating code or data
+in support of exceptions being thrown by a function. But this is
+unnecessary, because exceptions are disabled.</p>
+<p>The second is to allow the compiler and library code to choose
+different algorithms, depending on whether some function may throw
+exceptions. This is only relevant to a certain set of functions.</p>
+<ul>
+<li><p>Some allocation functions (<code>operator new</code> and
+<code>operator new[]</code>) return <code>nullptr</code> to indicate
+allocation failure. If a <code>new</code> expression calls such an
+allocation function, it must check for and handle that possibility.
+Declaring such a function <code>noexcept</code> informs the compiler
+that <code>nullptr</code> is a possible result. If an allocation
+function is not declared <code>noexcept</code> then the compiler may
+elide that checking and handling for a <code>new</code> expression
+calling that function.</p></li>
+<li><p>Certain Standard Library facilities (notably containers) provide
+different guarantees for some operations (and may choose different
+algorithms to implement those operations), depending on whether certain
+functions (constructors, copy/move operations, swap) are nothrow or not.
+They detect this using type traits that test whether a function is
+declared <code>noexcept</code>. This can have a significant performance
+impact if, for example, copying is chosen over a potentially throwing
+move. But this isn't relevant, since HotSpot forbids the use of most
+Standard Library facilities.</p></li>
+</ul>
+<p>HotSpot code can assume no exceptions will ever be thrown, even from
+functions not declared <code>noexcept</code>. So HotSpot code doesn't
+ever need to check, either with conditional exception specifications or
+with <code>noexcept</code> expressions.</p>
+<p>Dynamic exception specifications were deprecated in C++11. C++17
+removed all but <code>throw()</code>, with that remaining a deprecated
+equivalent to <code>noexcept</code>.</p>
 <h3 id="additional-permitted-features">Additional Permitted
 Features</h3>
 <ul>
@@ -1198,12 +1281,6 @@ <h3 id="excluded-features">Excluded Features</h3>
 href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html">n2179</a>)
 — HotSpot does not permit the use of exceptions, so this feature isn't
 useful.</p></li>
-<li><p>Avoid non-local variables with non-constexpr initialization. In
-particular, avoid variables with types requiring non-trivial
-initialization or destruction. Initialization order problems can be
-difficult to deal with and lead to surprises, as can destruction
-ordering. HotSpot doesn't generally try to cleanup on exit, and running
-destructors at exit can also lead to problems.</p></li>
 <li><p>Avoid most operator overloading, preferring named functions. When
 operator overloading is used, ensure the semantics conform to the normal
 expected behavior of the operation.</p></li>

doc/hotspot-style.md

@@ -770,6 +770,32 @@ ordering, which may differ from (may be stronger than) sequentially
 consistent.  There are algorithms in HotSpot that are believed to rely
 on that ordering.
 
+### Initializing variables with static storage duration
+
+Variables with static storage duration and _dynamic initialization_
+[C++14 3.6.2](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf)).
+should be avoided, unless an implementation is permitted to perform the
+initialization as a static initialization. The order in which dynamic
+initializations occur is incompletely specified.  Initialization order
+problems can be difficult to deal with and lead to surprises.
+
+Variables with static storage duration and non-trivial destructors should be
+avoided. HotSpot doesn't generally try to cleanup on exit, and running
+destructors at exit can lead to problems.
+
+Some of the approaches used in HotSpot to avoid dynamic initialization
+include:
+
+* Use the `Deferred<T>` class template. Add a call to its initialization
+function at an appropriate place during VM initialization. The underlying
+object is never destroyed.
+
+* For objects of class type, use a variable whose value is a pointer to the
+class, initialized to `nullptr`. Provide an initialization function that sets
+the variable to a dynamically allocated object. Add a call to that function at
+an appropriate place during VM initialization. Such objects are usually never
+destroyed.
+
 ### Uniform Initialization
 
 The use of _uniform initialization_
@@ -1104,6 +1130,57 @@ The following attributes are expressly forbidden:
 * `[[carries_dependency]]` - Related to `memory_order_consume`.
 * `[[deprecated]]` - Not relevant in HotSpot code.
 
+### noexcept
+
+Use of `noexcept` exception specifications
+([n3050](http://wg21.link/n3050))
+are permitted with restrictions described below.
+
+* Only the argument-less form of `noexcept` exception specifications are
+permitted.
+* Allocation functions that may return `nullptr` to indicate allocation
+failure must be declared `noexcept`.
+* All other uses of `noexcept` exception specifications are forbidden.
+* `noexcept` expressions are forbidden.
+* Dynamic exception specifications are forbidden.
+
+HotSpot is built with exceptions disabled, e.g. compile with `-fno-exceptions`
+(gcc, clang) or no `/EH` option (MSVC++). So why do we need to consider
+`noexcept` at all? It's because `noexcept` exception specifications serve two
+distinct purposes.
+
+The first is to allow the compiler to avoid generating code or data in support
+of exceptions being thrown by a function. But this is unnecessary, because
+exceptions are disabled.
+
+The second is to allow the compiler and library code to choose different
+algorithms, depending on whether some function may throw exceptions. This is
+only relevant to a certain set of functions.
+
+* Some allocation functions (`operator new` and `operator new[]`) return
+`nullptr` to indicate allocation failure. If a `new` expression calls such an
+allocation function, it must check for and handle that possibility. Declaring
+such a function `noexcept` informs the compiler that `nullptr` is a possible
+result. If an allocation function is not declared `noexcept` then the compiler
+may elide that checking and handling for a `new` expression calling that
+function.
+
+* Certain Standard Library facilities (notably containers) provide different
+guarantees for some operations (and may choose different algorithms to
+implement those operations), depending on whether certain functions
+(constructors, copy/move operations, swap) are nothrow or not. They detect
+this using type traits that test whether a function is declared `noexcept`.
+This can have a significant performance impact if, for example, copying is
+chosen over a potentially throwing move. But this isn't relevant, since
+HotSpot forbids the use of most Standard Library facilities.
+
+HotSpot code can assume no exceptions will ever be thrown, even from functions
+not declared `noexcept`. So HotSpot code doesn't ever need to check, either
+with conditional exception specifications or with `noexcept` expressions.
+
+Dynamic exception specifications were deprecated in C++11. C++17 removed all
+but `throw()`, with that remaining a deprecated equivalent to `noexcept`.
+
 ### Additional Permitted Features
 
 * `alignof`
@@ -1199,13 +1276,6 @@ namespace std;` to avoid needing to qualify Standard Library names.
 ([n2179](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html)) &mdash;
 HotSpot does not permit the use of exceptions, so this feature isn't useful.
 
-* Avoid non-local variables with non-constexpr initialization.
-In particular, avoid variables with types requiring non-trivial
-initialization or destruction.  Initialization order problems can be
-difficult to deal with and lead to surprises, as can destruction
-ordering.  HotSpot doesn't generally try to cleanup on exit, and
-running destructors at exit can also lead to problems.
-
 * Avoid most operator overloading, preferring named functions.  When
 operator overloading is used, ensure the semantics conform to the
 normal expected behavior of the operation.

src/hotspot/cpu/aarch64/aarch64.ad

@@ -1765,9 +1765,6 @@ void MachPrologNode::format(PhaseRegAlloc *ra_, outputStream *st) const {
 void MachPrologNode::emit(C2_MacroAssembler *masm, PhaseRegAlloc *ra_) const {
   Compile* C = ra_->C;
 
-  // insert a nop at the start of the prolog so we can patch in a
-  // branch if we need to invalidate the method later
-  __ nop();
 
   __ verified_entry(C, 0);
 
@@ -2167,10 +2164,6 @@ void MachVEPNode::emit(C2_MacroAssembler *masm, PhaseRegAlloc* ra_) const
   if (!_verified) {
     __ ic_check(1);
   } else {
-    // insert a nop at the start of the prolog so we can patch in a
-    // branch if we need to invalidate the method later
-    __ nop();
-
     // TODO 8284443 Avoid creation of temporary frame
     if (ra_->C->stub_function() == nullptr) {
       __ verified_entry(ra_->C, 0);

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp

@@ -1122,31 +1122,16 @@ void InterpreterMacroAssembler::update_mdp_for_ret(Register return_bci) {
 }
 
 
-void InterpreterMacroAssembler::profile_taken_branch(Register mdp,
-                                                     Register bumped_count) {
+void InterpreterMacroAssembler::profile_taken_branch(Register mdp) {
   if (ProfileInterpreter) {
     Label profile_continue;
 
     // If no method data exists, go to profile_continue.
-    // Otherwise, assign to mdp
     test_method_data_pointer(mdp, profile_continue);
 
     // We are taking a branch.  Increment the taken count.
-    // We inline increment_mdp_data_at to return bumped_count in a register
-    //increment_mdp_data_at(mdp, in_bytes(JumpData::taken_offset()));
-    Address data(mdp, in_bytes(JumpData::taken_offset()));
-    ldr(bumped_count, data);
-    assert(DataLayout::counter_increment == 1,
-            "flow-free idiom only works with 1");
-    // Intel does this to catch overflow
-    // addptr(bumped_count, DataLayout::counter_increment);
-    // sbbptr(bumped_count, 0);
-    // so we do this
-    adds(bumped_count, bumped_count, DataLayout::counter_increment);
-    Label L;
-    br(Assembler::CS, L);       // skip store if counter overflow
-    str(bumped_count, data);
-    bind(L);
+    increment_mdp_data_at(mdp, in_bytes(JumpData::taken_offset()));
+
     // The method data pointer needs to be updated to reflect the new target.
     update_mdp_by_offset(mdp, in_bytes(JumpData::displacement_offset()));
     bind(profile_continue);
@@ -1161,7 +1146,7 @@ void InterpreterMacroAssembler::profile_not_taken_branch(Register mdp, bool acmp
     // If no method data exists, go to profile_continue.
     test_method_data_pointer(mdp, profile_continue);
 
-    // We are taking a branch.  Increment the not taken count.
+    // We are not taking a branch.  Increment the not taken count.
     increment_mdp_data_at(mdp, in_bytes(BranchData::not_taken_offset()));
 
     // The method data pointer needs to be updated to correspond to

src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp

@@ -298,7 +298,7 @@ class InterpreterMacroAssembler: public MacroAssembler {
   // narrow int return value
   void narrow(Register result);
 
-  void profile_taken_branch(Register mdp, Register bumped_count);
+  void profile_taken_branch(Register mdp);
   void profile_not_taken_branch(Register mdp, bool acmp = false);
   void profile_call(Register mdp);
   void profile_final_call(Register mdp);

src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp

@@ -212,11 +212,6 @@ void NativeMovRegMem::verify() {
 
 void NativeJump::verify() { ; }
 
-
-void NativeJump::check_verified_entry_alignment(address entry, address verified_entry) {
-}
-
-
 address NativeJump::jump_destination() const          {
   address dest = MacroAssembler::target_addr_for_insn_or_null(instruction_address());
 
@@ -345,10 +340,6 @@ bool NativeInstruction::is_movk() {
   return Instruction_aarch64::extract(int_at(0), 30, 23) == 0b11100101;
 }
 
-bool NativeInstruction::is_sigill_not_entrant() {
-  return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead
-}
-
 void NativeIllegalInstruction::insert(address code_pos) {
   *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead
 }
@@ -359,31 +350,6 @@ bool NativeInstruction::is_stop() {
 
 //-------------------------------------------------------------------
 
-// MT-safe inserting of a jump over a jump or a nop (used by
-// nmethod::make_not_entrant)
-
-void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) {
-
-  assert(dest == SharedRuntime::get_handle_wrong_method_stub(), "expected fixed destination of patch");
-  assert(nativeInstruction_at(verified_entry)->is_jump_or_nop()
-         || nativeInstruction_at(verified_entry)->is_sigill_not_entrant(),
-         "Aarch64 cannot replace non-jump with jump");
-
-  // Patch this nmethod atomically.
-  if (Assembler::reachable_from_branch_at(verified_entry, dest)) {
-    ptrdiff_t disp = dest - verified_entry;
-    guarantee(disp < 1 << 27 && disp > - (1 << 27), "branch overflow");
-
-    unsigned int insn = (0b000101 << 26) | ((disp >> 2) & 0x3ffffff);
-    *(unsigned int*)verified_entry = insn;
-  } else {
-    // We use an illegal instruction for marking a method as not_entrant.
-    NativeIllegalInstruction::insert(verified_entry);
-  }
-
-  ICache::invalidate_range(verified_entry, instruction_size);
-}
-
 void NativeGeneralJump::verify() {  }
 
 // MT-safe patching of a long jump instruction.

src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp

@@ -83,7 +83,6 @@ class NativeInstruction {
   bool is_safepoint_poll();
   bool is_movz();
   bool is_movk();
-  bool is_sigill_not_entrant();
   bool is_stop();
 
 protected:
@@ -360,9 +359,6 @@ class NativeJump: public NativeInstruction {
 
   // Insertion of native jump instruction
   static void insert(address code_pos, address entry);
-  // MT-safe insertion of native jump at verified method entry
-  static void check_verified_entry_alignment(address entry, address verified_entry);
-  static void patch_verified_entry(address entry, address verified_entry, address dest);
 };
 
 inline NativeJump* nativeJump_at(address address) {