configure and will not work. The maximum accepted version
-of Visual Studio is 2022.
+of Visual Studio is 2026.
If you have multiple versions of Visual Studio installed,
configure will by default pick the latest. You can request
a specific version to be used by setting
diff --git a/doc/building.md b/doc/building.md
index 047255d1848..1fbd395a9d1 100644
--- a/doc/building.md
+++ b/doc/building.md
@@ -468,7 +468,7 @@ available for this update.
The minimum accepted version is Visual Studio 2019 version 16.8. (Note that
this version is often presented as "MSVC 14.28", and reported by cl.exe as
19.28.) Older versions will not be accepted by `configure` and will not work.
-The maximum accepted version of Visual Studio is 2022.
+The maximum accepted version of Visual Studio is 2026.
If you have multiple versions of Visual Studio installed, `configure` will by
default pick the latest. You can request a specific version to be used by
diff --git a/doc/hotspot-style.html b/doc/hotspot-style.html
index fb4cffc9d43..a2ffb57e5a3 100644
--- a/doc/hotspot-style.html
+++ b/doc/hotspot-style.html
@@ -86,8 +86,9 @@ values
This section describes that subset. Features from the C++98/03 -language may be used unless explicitly excluded here. Features from +language may be used unless explicitly forbidden here. Features from C++11, C++14, and C++17 may be explicitly permitted or explicitly -excluded, and discussed accordingly here. There is a third category, +forbidden, and discussed accordingly here. There is a third category, undecided features, about which HotSpot developers have not yet reached a consensus, or perhaps have not discussed at all. Use of these features -is also excluded.
+is also forbidden.(The use of some features may not be immediately obvious and may slip in anyway, since the compiler will accept them. The code review process is the main defense against this.)
Some features are discussed in their own subsection, typically to provide more extensive discussion or rationale for limitations. Features that don't have their own subsection are listed in omnibus feature -sections for permitted, excluded, and undecided features.
+sections for permitted, forbidden, and undecided features.Lists of new features for C++11, C++14, and C++17, along with links to their descriptions, can be found in the online documentation for some of the compilers and libraries. The C++17 Standard is the definitive @@ -593,14 +594,15 @@ title="Runtime Type Information">RTTI
are deemed not worthwhile, given the alternatives.Do not use the standard global allocation and deallocation functions -(operator new and related functions). Use of these functions by HotSpot -code is disabled for some platforms.
+(globaloperator new and related functions), other than the
+non-allocating forms of those functions. Use of these functions by
+HotSpot code is disabled for some platforms.
Rationale: HotSpot often uses "resource" or "arena" allocation. Even where heap allocation is used, the standard global functions are avoided -in favor of wrappers around malloc and free that support the VM's Native -Memory Tracking (NMT) feature. Typically, uses of the global operator -new are inadvertent and therefore often associated with memory -leaks.
+in favor of wrappers aroundmalloc and free
+that support the JVM's Native Memory Tracking (NMT) feature. Typically,
+uses of the global operator new are inadvertent and
+therefore often associated with memory leaks.
Native memory allocation failures are often treated as non-recoverable. The place where "out of memory" is (first) detected may be an innocent bystander, unrelated to the actual culprit.
@@ -647,7 +649,39 @@ for anonymous namespaces. class="uri">https://sourceware.org/bugzilla/show_bug.cgi?id=16874Avoid using the C++ Standard Library.
+Only curated parts of the C++ Standard Library may be used by HotSpot +code.
+Functions that may throw exceptions must not be used. This is in +accordance with the HotSpot policy of not +using exceptions.
+Also in accordance with HotSpot policy, the standard global allocator must not be +used. This means that uses of standard container classes cannot +presently be used, as doing so requires specialization on some allocator +type that is integrated with the existing HotSpot allocation mechanisms. +(Such allocators may be provided in the future.)
+Standard Library identifiers should usually be fully qualified;
+using directives must not be used to bring Standard Library
+identifiers into scope just to remove the need for namespace
+qualification. Requiring qualification makes it easy to distinguish
+between references to external libraries and code that is part of
+HotSpot.
As with language features, Standard Library facilities are either +permitted, explicitly forbidden, or undecided (and so implicitly +forbidden).
+Most HotSpot code should not directly #include C++
+Standard Library headers. HotSpot provides a set of wrapper headers for
+the Standard Library headers containing permitted definitions. These
+wrappers are in the cppstdlib directory, with the same name
+as the corresponding Standard Library header and a .hpp
+extension. These wrappers provide a place for any additional code (some
+of which may be platform-specific) needed to support HotSpot usage.
These wrappers also provide a place to document HotSpot usage, +including any restrictions. The set of wrappers and the usage +documentation should be considered part of HotSpot style. Any changes +are subject to the same process as applies to this document. (For +historical reasons, there may be many direct inclusions of some C++ +Standard Library headers.)
Historically, HotSpot has mostly avoided use of the Standard Library.
(It used to be impossible to use most of it in shared code, because @@ -660,46 +694,60 @@ in mid-2017. Support for Solaris was removed in 2020.)
of Standard Library facilities is exceptions. HotSpot does not use exceptions and, for platforms which allow doing so, builds with them turned off. Many Standard Library facilities implicitly or explicitly -use exceptions.assert. An issue that is quickly encountered is the
assert macro name collision (JDK-8007770).
-Some mechanism for addressing this would be needed before much of the
-Standard Library could be used. (Not all Standard Library
-implementations use assert in header files, but some do.)
assert in
+header files, but some do.) HotSpot provides a mechanism for addressing
+this, by establishing a scope around the include of a library header
+where the HotSpot assert macro is suppressed. One of the
+reasons for using wrapper headers rather than directly including
+standard headers is to provide a central place to deal with this issue
+for each header.
Memory allocation. HotSpot requires explicit control over where
allocations occur. The C++98/03 std::allocator class is too
-limited to support our usage. (Changes in more recent Standards may
-remove this limitation.)
Implementation vagaries. Bugs, or simply different implementation choices, can lead to different behaviors among the various Standard -Libraries we need to deal with.
Inconsistent naming conventions. HotSpot and the C++ Standard use different naming conventions. The coexistence of those different -conventions might appear jarring and reduce readability.
There are a few exceptions to this rule.
+conventions might appear jarring and reduce readability. However, +experience in some other code bases suggests this isn't a significant +problem, so long as Standard Library names are namespace-qualified. It +is tempting to bring the Standard Library names into scope via a +using std; directive. Doing so makes writing code using
+those names easier, since the qualifiers don't need to be included. But
+there are several reasons not to do that.
#include <new> to use placement new,
-std::nothrow, and std::nothrow_t.#include <limits> to use
-std::numeric_limits.#include <type_traits> with some restrictions,
-listed below.#include <cstddef> to use
-std::nullptr_t and std::max_align_t.There is a risk of future name collisions. Additional Standard +Library headers may be included, adding to the list of names being used. +Also, future versions of the Standard Library may add currently unknown +names to the headers already being included.
It may harm readability. Code where this is relevant is a mixture +of the local HotSpot naming conventions and the Standard Library's (or +other 3rd-party library's) naming conventions. With only unqualified +names, any distinctions from the naming conventions for the different +code sources are lost. Instead one may end up with an undifferentiated +mess, where it's not obvious whether an identifier is from local code +that is inconsistent with HotSpot style (and there's a regretable amount +of that for historical reasons), or is following some other convention. +Having the qualifiers disambiguates that.
It can be helpful to know, at a glance, whether the definition is +in HotSpot or elsewhere, for purposes of looking up the definition or +documentation.
Certain restrictions apply to the declarations provided by
-<type_traits>.
alignof operator should be used rather than
-std::alignment_of<>.TODO: Rather than directly #including (permitted) Standard Library -headers, use a convention of #including wrapper headers (in some -location like hotspot/shared/stdcpp). This provides a single place for -dealing with issues we might have for any given header, esp. -platform-specific issues.
Use type deduction only if it makes the code clearer or safer. Do not use it merely to avoid the inconvenience of writing an explicit type, @@ -937,12 +985,18 @@ 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. -Variables with static storage duration may be declared
- The use of variable templates (including static data member
+templates) (N3651) is permitted.
+They provide parameterized variables and constants in a simple and
+direct form, instead of requiring the use of various workarounds. Variables with static storage duration and variable templates may be
+declared inline (p0386r2).
-This has similar effects as for declaring a function inline: it can be
-defined, identically, in multiple translation units, must be defined in
-every translation unit in which it is Variable Templates and
+Inline Variables
+inline (p0386r2), and this usage is
+permitted. This has similar effects as for declaring a function inline:
+it can be defined, identically, in multiple translation units, must be
+defined in every translation unit in which it is ODR used, and the behavior of the
program is as if there is exactly one variable.
A constexpr static data member is implicitly
-inline. As a consequence, an A constexpr static data member or static data member
+template is implicitly inline. As a consequence, an ODR use of such a variable doesn't
-require a definition in some .cpp file. (This is a change from
-pre-C++17. Beginning with C++17, such a definition is considered a
-duplicate definition, and is deprecated.)
Declaring a thread_local variable inline is
-forbidden for HotSpot code. The use of
-thread_local is already heavily restricted.
Declaring a thread_local variable template or
+inline variable is forbidden in HotSpot code. The use of thread_local is already
+heavily restricted.
Allow typename in template template parameter (n4051) — template template parameters
are barely used (if at all) in HotSpot, but there's no reason to
-artificially disallow this syntactic regularization in any such
+artificially forbid this syntactic regularization in any such
uses.
The use of structured bindings p0217r3 is forbidden. Preferred @@ -1614,8 +1669,33 @@ initialization for classes with base classes (p0017r1). HotSpot makes very little use of aggregate classes, preferring explicit constructors even for very simple classes.
-<algorithm>, <iterator>,
+<numeric>
Not useful without standard containers
+or similar classes in HotSpot.
<bitset> - Overlap with HotSpot
+BitMap.
<cassert>, assert.h - HotSpot has
+its own assert macro.
<exception>, <stdexcept> -
+Use of exceptions is not
+permitted.
Thread support - <thread>,
+<mutex>, <shared_mutex>,
+<condition_varible>, <future>
+HotSpot has its own threading support.
Streams - HotSpot doesn't use the C++ I/O library.
<scoped_allocator> - Not useful without
+specialized allocators.
<string> - Requires allocator support, similar
+to standard containers.
<typeinfo>, <typeindex>
+Use of runtime type information
+is not permitted.
<valarray> - May allocate, but is not
+allocator-aware.
New string and character literals
Trailing return type syntax for functions (n2541)
Member initializers and aggregates (n3653)
Rvalue references and move semantics
<tuple>
+— Prefer named access to class objects, rather than indexed access to
+anonymous heterogeneous sequences. In particular, a standard-layout
+class is preferred to a tuple.
std::invoke<>() (n4169)
<chrono>
+— The argument for chrono is that our existing APIs aren't serving us
+well. chrono provides strong type safety. We've had multiple cases of
+mistakes like a double seconds being treated as double milliseconds or
+vice versa, and other similar errors. But it would be a large effort to
+adopt chrono. We'd also need to decide whether to use the predefined
+clocks or hook up chrono to our clocks. It may be that using the
+predefined clocks is fine, but it's a question that needs careful
+study.
<initializer_list>
+— The potential ambiguity between some forms of direct initialization
+and initializer list initialization, and the resolution of that
+ambiguity, is unfortunate.
<ratio>
+— <ratio> is a compile-time rational
+arithmetic package. It's also fixed (though parameterized) precision.
+It's not a general purpose rational arithmetic facility. It appears to
+have started out as an implementation detail of chrono, and was
+extracted and promoted to a public facility in the belief that it has
+broader utility.
<system_error>
+— We don't really have a generally agreed upon mechanism for managing
+errors. Instead, we have a plethora of bespoke ad hoc mechanisms.
+Managing errors is a topic of substantial discussion.
+<system_error> might end up being a part of a result
+from that discussion.