diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 0e64ad78625..8c058440ad7 100644 --- a/.github/workflows/main.yml +++ b/.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' diff --git a/doc/hotspot-style.html b/doc/hotspot-style.html index d4c06fbd6bd..dafd29d6f54 100644 --- a/doc/hotspot-style.html +++ b/doc/hotspot-style.html @@ -77,6 +77,9 @@ SFINAE
  • thread_local
  • nullptr
  • <atomic>
  • +
  • Initializing +variables with static storage duration
  • Uniform Initialization
  • Local Function Objects
  • Inheriting constructors
  • Attributes
  • +
  • noexcept
  • Additional Permitted Features
  • @@ -791,6 +795,33 @@ differ from what the Java compilers implement.

    "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.

    +

    Initializing +variables with static storage duration

    +

    Variables with static storage duration and dynamic +initialization C++14 +3.6.2). 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:

    +

    Uniform Initialization

    The use of uniform initialization (n2672), @@ -1110,6 +1141,58 @@ function name and the parameter list. memory_order_consume.

  • [[deprecated]] - Not relevant in HotSpot code.
  • +

    noexcept

    +

    Use of noexcept exception specifications (n3050) are permitted with restrictions +described below.

    + +

    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.

    + +

    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